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I-  INTRODUCTION 

Software  portability,  as  defined  by  Poole  an  3  Waite 
[fief.  1  1t  is  the  measure  of  the  ease  which  a  program  car,  be 
transferred  from  one  environment  to  another;  if  the  effort 
required  to  move  the  program  is  much  less  than  that  required 
to  implement  it  initially,  and  the  effort  is  small  in  an 
absolute  sense,  then  that  program  is  highly  portable. 

Software  portability  has  become  an  area  of  intense 
researcii  as  the  "software  crisis"  continues  to  gain 
momentum.  The  less  portable  a  program  is,  the  more  it  will 
cost  in  terms  of  time  and  money  to  transfer  it  to  another 
machine.  One  important  impact  of  the  lack  of  portability  is 
that  there  will  be  little  incentive  to  create  truly  user 
friendly  environments  since  the  cost  of  producing  such  a 
system  can  not  be  amortized  over  many  machine 
implementations. 

There  have  been  many  attempts  to  solve  the  portability 
problem.  Many  approaches  have  failed,  some  approaches  have 
achieved  limited  success,  few  have  provide!  a  broadhased 
methodology  for  achieving  portability.  High  level  languages 
were  one  of  the  first  attempts  at  resolving  the  problem. 
They,  however,  were  either  too  small  to  be  useful,  and 
conseguenteiy  extended,  or  too  large  and  therefore  subseted. 
Even  if  the  language  achieved  a  great  deal  of:  consistency 
over  many  implementation,  programs  were  still  desigr.ee  with 
non-standard,  machine  dependent  features. 

Decompilers  and  language  translators  were  developed  but 
their  complexity  and  poor  reliability  discouraged  furthei 
development 

The  use  of  specifications  to  define  the  behavior  of  a 
program   is   a   method   which  offers   a.   way   to   solve   the 


portability  problem.  Although  more  work  is  required  to  coco 
from  a  specif ication,  the  description  of  t.:o3ioE  behavior 
can  be  more  precise  and  implementation  independence  is 
possible.  Complications  arise,  however,  when  the  specifica- 
tion language  is  ambiguous.  Formal  specification  languages 
based  on  mathematical  principles  alleviate  this  problem  but 
often  are  more  difficult  to  use  and  frequently  larger  than 
the  programs  they  specify.  Despite  the  difficulty  in  their 
use,  formal  specifications  offer  the  greatest  degree,  of 
freedom  from  implementation  without  ambiguity. 

A  specification  methodology  based  on  initial  algebras 
promises  to  be  a  viable  answer  to  the  portability  problem 
witnout  the  drawbacks  of  most  formal  specification 
technigues. 


Algebras   have   a   wide  range   of   applications 


my 


researchers  have  proposed  treating  abstract  data  types  as 
algebras  [Ref.  2],  [Ref.  3],  [fief-  4].  Algebras  are  partic- 
ularly well  suited  for  describing  data  types;  data  types 
consist    of    data    elements   and    operations   on    the    lata    elements 


which    is   essentially    the    definition 


i^gebra, 


r ao ex  , 


in    his    thesis    [Ref.     5],       noted    that      if    algebras    can    be    us< 
to    specify    data       types,       then    the    next    step    woul  I 


Ko 


t  o  us  e 


them  to  specify  languages;  a  program  is  composed  of  instruc- 
tions which  can  be  expressed  using  algebras.  Furthermore, 
research  at  the  Naval  Postgraduate  Scnooi  is  aimed  at  using 
algebras  to  specify  an  abstract  machine.  A  machine  can  be 
described  using  algebras  since  the  execution  of  instructions 
causes  the  machine  to  change  state.  Algebras  are  used  to 
define  the  effect  each  instruction  has  on  the  state  of  the 
machine . 

tut  simply,  by  using  algebras,  formal  specifications  can 
be  produced _  which  are  truly  independent  of  an  implementa- 
tion; many  implementations  of  the  specification  can  be 
created  which  emulate  a   formal  algebraic  specification.   In 
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addition,   it  is   possible  and  mora  reasonable   to  prove  th< 
correctness  of  an  implement a tion  developed  from  an  algebraic 
specification. 

If  the  research  at  the  Naval  Postgraduate  School  is 
successful  in  specifying  an  abstract  aacnine,  software  can 
then  be  targeted  for  the  abstract  machine  and  freed  from 
machine  dependence.  A  simpler  layer  of  software  will  trans- 
late the  abstract  uachine  commands  into  a  particular  machine 
code.  A  tremendous  savings  can  be  realized  when  complex 
software,  such  as  software  that  supports  a  user  friendly 
environment,  is  targeted  for  this  machine.  Futhermore,  it 
may  be  feasible  to  determine  if  one  abstract  machine  is 
equivalent  to  another  because  of  the  precise  algebraic  spec- 
ifications. Equivalent  distract  machines  would  imply  a  way 
of  translating  software  to  different  machines. 

The  intent  of  this  thesis  is  to  define  a  suitable 
language  for  an  algebraic  specification  which  minimizes  the 
problem  with  using  this  methodlogy,  and  to  implement  an 
experimental  syntax  directed  editor  using  this  language. 
Chapter  two  provides  the  background  theory  of  specifications 
based  on  algebras.  Chapter  three  describes  the  various  parts 
of  an  algebraic  specification  and  the  corresponding  parts  in 
the  proposed  language.  Chapter  four  describes  a  syntax 
directed  editor  for  the  language. 


1  1 


II.     SPECIFICATIONS     BASED    ON    ALGEBRAS 

The  purpose  of  this  chapter  is  to  provide  an  introduc- 
tion to  algebras  used  for  specifications.  Gog u en  et  ai's 
work  using  algebras  to  specify  abstract  data  types  provides 
the  basis  for  the  language  presented  in  the  next  chapter 
[Ref.  2].  A  review  of  definitions  and  terms  used  in  the 
algebras  they  discuss  is  worthwhile  before  introducing  the 
specification   language. 

A.       A    REVIEW    OF    ALGEERAS 

An  algebra  consists  of  a  set,  called  the  carrier  of  the 
algebra,  an  operator  defined  on  the  carrier  and  distin- 
guished elements  of  the  carrier,  called  the  constants.  They 
are      normally    represented      using      a      bracketed    tuple.  For 

example,         the       addition      operator         on      integers       would      be 
expressed   as    follows: 

<  I ,  +  ,  0> 

The  carrier  set«*can  be  of  any  one  type  we  wish  to  manip- 
ulate such  as  real  numbers,  integers  or  character  strings. 
For  the  addition  operator  on  integers,  the  carrier  set  is 
identified  by  the  capital  letter  I  and  the  eieuents  of  the 
carrier  set  are  the  integers.  The  di  stin^j  jisaed  element  of  I 
is  z  e  ro  . 

An  operation  is  a  mapping  taking  one  or  more  elements  in 
the  carrier  to  an  element  in  the  carrier.  For  example,  the 
addition  operator  on  integers  will  take  two  integers  and  map 
them  to  an  integer  as  shown  in  rigure  2.1  . 

It  is  common  practice  to  refer  to  a  specific  class  of 
algebras.   The  members   of  a  particular  class   have  the  same 
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signature  or  "arity"  in  their  operators  [Re£.  2].  ro: 
instance,  the  subtraction,  addition  anl  multiplication  oper- 
ators on  integers  are  members  of  the  same  class  since  they 
have  the  same  signature;  they  map  two  integers  to  one 
integer . 


Integers 


Figure  2.1    Mapping  of  integers. 

The  constants  or  distinguished  elements  of  the  carrier 
usually  have  special  properties.  The  numner  zero  in  the 
integers  has  a  special  property  in  regards  to  the  addition 
operator;  any  number  added  to  zero  will  .nap  jack.  to  that 
number  as  shown  in  Figure  2-2  .  Algebraic  specif ications 
will  not  explicitly  deal  with  distinguished  elements. 
Instead,  constant  operators  are  used  to  describe  the  distin- 
guished elements.  This  is  done  to  achieve  implement  at ion 
independence  in  the  specif icaticn. 

An  algebra  is  not  usually  interesting  unless  it  has  som^ 
specific  structure.  The  structure  is  defined  by  axioms. 
Using  the  above   example,   the  addition  operator   as  defined 
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In  tegers 


Figure  2.2    A  Constant  flapping. 

will  not  Le  useful  if  every  application  of  the  operator 
mapped  an  element  to  the  same  element.  Therefore  restric- 
tions on  the  behavior  of  the  addition  operator  are  defined 
vhich  limit  the  mapping.  Later  it  will  be  shown  how  axioms 
define  the  behavior  of  operators  in  an  algebraic 
specification. 


B, 


SIGHA   OR    MANY    SOETED    ALGEBEAS 


An  algebra  with  one  carrier  set  and  mapping  is  not 
particularly  useful  for  the  purpose  of  specifications.  For 
instance,  in  defining  a  stack  as  an  abstract  data  type  using 
algebras,  we  would  not  want  to  be  limited  to  one  type  of 
data  the  stack  contains  such  as  a  stack  of  integers.  Instead 
we  would  like  to  talk  about  a  stack  of.  integers,  reals, 
booleans,  etc.  Therefore  in  specifying  an  algebra  for  a 
stack,  a  'sort'  set  would  be  defined.  Each  element  of  th« 
sort  set  would  be  an  index  to  a  carrier  set;  the  sort  would 
identify  the  carrier  set.  A  stack  data  type  can  then  be 
defined    as    having   a    sort    set    as   follows: 

S=  (in tegers, boolean, stack, reals} 
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Each  element  in  the  set  5  represents  a  carrier.  Nov  it  is 
possible  to  define  a  stack  of  reals,  integers,  and  boolean 
values.  Notice  that  a  stack  also  is  a  sort;  a  stack  is  a 
different  object  after  operations  are  performed  on  it.  As  a 
result/  stack  is  also  a  carrier  set. 

In  addition  to  the  many  scrts  of  an  algebra,  it.  is 
desirable  to  have  various  operators  on  the  sorts.  Operators 
on  the  data  type  are  defined  by  mappings  from  zero  or  icore 
elements  from  carrier  (s)  to  an  element  in  a  carrier  set. 
Using  the  stack  example,  the  pusn  operator  can  be  defined 
as : 

push:  integer, stack  ->  stack 

The  meaning  of  this  operator  is  that  given  an  element  from 
each  of  the  carriers  identified  by  integer  and  stack,  the 
push  operator  produces  an  element  in  the  carrier  identified 
Ly  stack.  This  is  depicted  in  Figure  2.3  . 


integers 


Figure    2.3        The    Push    Operator, 
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The  operators  in  an  algearaic  specification  ait  given  cy 
a  sorted  signature,.  Sigma,  or  operator  domain,  which  is  a 
family  of  sets.  Each  set  of  the  family  contains  a  partic- 
ular domain  for  a  group  of  operators.  These  ail  have  the 
"arity"  discussed  in  the  previous  section.  Using  the  sr.  ick 
example,  the  arity  Sigma (integer  stack, stack)  defines  a 
domain  for  those  operators  which  ma^  an  integer  and  a  stack 
to  a  stack.  The  push  operator  would  be  a  member  of  this 
domain.  Any  other  operator  which  took  an  integer  and  jl 
stack  and  mapped  it  to  a  stack  would  have  the  same  arity. 

The  pop  operator  would  be  in  the  set  of  operators  given 
by  the  arity  Sigma  (s tack, stack)  .  If  there  was  an  operator 
which  removed  two  or  more  elements  from  a  stack,  it  would 
also  have  the  same  arity.  An  interesting  point  her*;  is  thar 
the  integer  which  is  removed  is  a  side  effect  which  must  be 
described  in  the  equations  for  the  operator.  All  of  the 
operators  defined  using  the  sort  set  are  collectively  known 
as  the  Sigma  signature 

Given  the  above,  a  specification  algebra  consists  ox  a 
sort  set  S,  a  Sigma  signature  on  the  sort  set,  and  named 
operators  for  each  signature.  Algebras  defined  as  tzdch  are 
called  many  sorted  algebras  or  Sigma  algebras  [Ref.  2]. 

C.   BOOLEAN  AS  A  SIGMA  ALGEBRA 

In  order  to  explain  tne  use  of  axioms,  a  development  of 
the  boolean  data  type  as  an  algebra  is  presented.  It  will 
specify  how  an  implementation  of  boolean  logic  should  behave 
if  used  in  a  program  or  a  machine. 

An  appropriate  sort  name  for  the  boolean  data  type  would 
be  bool  and  the  corresponding  sort  set  S  would  be  {bool} . 
Bool  is  the  only  sort  type  required  to  specify  the  boolean 
data  type.  The  carrier  set  that  bool  identifies  will  contain 
two  elements  {T,F}.    Although  two  specific  elements   of  the 
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carrier  have  been  described  here,  an  impiementor  may  choose 
different  representations  for  the  elements  of  the  carrier;  a 
carrier  with  elements  {0,1}  would  work  equally  veil.  In  an 
algebraic  specif icatiuii,  the  elements  of  the  carrier  are  not 
specifically  defined  so  the  implement or  may  choose  any 
representation  for  carrier  elements.  In  this  way,  a  speci- 
fier can  achieve  implementation  independence.  However,  for 
the  purpose  of  clarity,  the  elements  of  the  carrier  will  be 
used  in  the  boolean  example  to  define  the  operators. 

The   five  boolean   operators  used   in  the   specification 
will  be  as  follows. 

1.  true  -  Returns  a  value  of  T. 

2.  false  -  Returns  a  value  of  F. 

3.  not  -  Returns  the  negaticn  of  a  valae. 
<4  .   implies  -  Implication 

5.   and  -  The  logical  'and'  operator. 
The  following  notation  will  be   adopted  for  operators  to 
describe  the  operand  sorts  and  the  resulting  sort. 

For  Sigma  (lambda,  booi) 

true  :  ->  tool 
false  :  ->  Dooi 

For  Sig  ma  (bool,  bool) 

not:  bool  ->  bool 

For  Sigma(bool  bool, bool) 

and:  bool/bool  ->  bool 
implies:  bool, bool  ->  bool 

The  notation  here  is  the  same  as  that  used  to  describe  the 
push  operator  in  the  last  section  and  will  be  the  same  no  ca- 
tion used  in  the  specification  language  presented  later. 
For  the  signature  Sigma (lambda ,  bool),  the  notation  means 
the  "true"  and  "false"  operators  produce  an  element  in  the 
carrier   set   identified   by   bool.      Lambda   is   used   in 
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conjunction  with  constant  operators;  constant  operators 
always  produce  t iie  same  element  and  they  appear  to  product 
something  from  nothing.  The  "net"  operator  tan.es  an  element 
from  the  carrier  set  identified  by  cool  and  produces  an 
element  in  the  bool  carrier  set.  The  "and"  and  "implies" 
signature  would  be  Sigma  (bool  bcoI,booi)  .  Tnat  means,  given 
two  elements  in  the  carrier  set  identified  by  bool,  the 
"and"  and  "implies"  operators  produce  an  element  in  the 
carrier  identified  by  bool. 

The  sigma  alyebra  for  boolean  at  this  point  is  not  very 
interesting.  This  is  because  the  operators  have  no  restric- 
tions on  their  behavior.  Consequently  most  implementations 
of  boolean  using  just  this  specification  would  not  ba 
useful.  For  example,  the  "not"  operator  would  be  correct  if 
it  took  any  element  in  the  carrier  set  and  produced  the  same 
element.  A  more  useful  Sigma  algebra  would  put  restriction^ 
on  the  operators.  This  j.s  accomplished  by  introducing 
axioms  or  equations  on  the  operators.  In  tne  Boolean  sigma 
algebra,  we  would  introduce  the  following  axioms: 

1  .   false  =  not  (true) 

2  .   not  (not  (v)  )  =  v 

3.  and (true, v)  =  v 

4.  and  (false, v)  =  false 

5.  implies (v 1 , v2)  =  not  (and  (v  1 ,  not  (v2 )  )  ) 

Notice  that  the  axioms  were  written  without  using  a 
explicit  reference  to  carrier  set  elements;  by  not  asiiij  T 
or  F  the  aata  type  achieves  implementation  independence. 

Implementations  of  the  boolean  data  type  are  now 
required  to  mimick  the  axioms  when  operators  are  applied. 
For  instance,  the  negation  operator,  "not",  now  behaves  as 
expected  and  any  implementation  would  have  to  rofiect  axioms 
one  and  two.  Axiom  one  shows  the  effect  "not"  has  on  an 
element  in  the  carrier  set.  Axiom  two  further  defines  tne 
behavior  of  "not"  by  showing  that  any  element  in  the  carrier 
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which  is  operated  ol  by  the  "riot"  operator  twice  :»ili 
produce  the  same  element. 

The  "and"  operator  behaves  as  depicted  by  equations 
three  and  four;  given  any  value  v1  "anded"  with  the  value 
produced  from  the  "true"  operator  will  result  in  that  value. 
Implies  is  defined  by  axiom  five  as  being  tiie  same  as  a 
combination  of  "not"  and  "and"  operators  using  the  same 
carrier  values. 

Note  that  with  the  exception  of  axiom  one,  all  the 
axioms  involve  variables  v,  v1  and  v2  which  can  be  assigned 
all  values  from  the  carrier  set  defined  for  the  operators 
"and"  "not"  and  "implies".  The  axioms  form  the  basis  of  all 
the  expressions  that  can  be  created  usinj  the  variables  and 
members  of  the  carrier  set.  This  means  that  an  expression 
which  is  built  from  other  expression  is  permissable  if  it 
reduces  to  an  element  of  the  carrier  set  through  the 
application  of  the  axioms. 

To  illustrate  this,  suppose  we  had  an  expression 

not  (and  (not  (v  1)  ,  v2)  ) 

If  v  1  is  assigned  the  element  I  and  v2  is  assigned  the 
element  F,  then  the  expression  becomes  the  following  b'y 
axiom    cne: 

not  (and  (F,F)  ) 

This  further  reduces  to  not  (F)  by  axiom  four.  Axiom  one- 
implies  that  this  reduces  to  I,  an  element  of  the  carrier. 

All  the  permissible  expressions  tnat  can  be  constructed 
from  the  operators  and  elements  of  the  carrier  are  collec- 
tively called  the  term  algebra.  The  algebra  that  represents 
all  the  expressions  that  can  be  made  up  of  variables  an  J 
operators  is  called  a  free  aigelra  [Ref-  2]. 

It  is  now  possible  to  define  a  specification  as  a  "pres- 
entation".    A  presentation   consists  of   a   sort  set,    an 
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operator  domain  Sigma,  awl  axions  on  the  operators.  A  pres- 
entation will  be  the  Lasis  for  the  specification  language, 
S^ecianj  ,  presented  in  the  the  next  chapter.  A  specf  icatior. 
developed  from  Speciang  is  comprise  of  one  or  nore  presenta- 
tions and  each  presentation  is  known  as  specif ication 
modules. 
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III.  A  SPECIFICATION  LANGUAGE 

liskov  and  Zilles  [Ref.  4]  Lave  developed  criteria  for 
evaluating  a  formal  specification  iangaage.  Their  v.'orh 
focuses  on  the  underlying  mechanism  used  in  formal  specifi- 
cation. They  compared  approaches  using  algebras,  finite 
state  machines,  mixed  mathematical  disciplines ,  etc.  Zhcj 
criteria  used  in  their  comparisons  are; 

1.  Formality  -  The  language  must  te  precise  and 
rigorous. 

2.  Constructabiiity  -  It  should  be  easy  to  construct  a 
specification  from  the  language. 

3.  Comprehensible  -  Is  the  specification  relatively  easy 
to  understand? 

4.  Minimality  -  The  specification  generated  should 
define  its  meaning  with  a  minimum  number  of  state- 
ments. One  flaw  of  formal  specifications  is  that  zhej 
frequently  require  more  statements  than  the  program 
they  specify. 

5.  Applicability  -  Can  the  language  be  asei  for  a  wide 
range  of  specifications? 

6.  Extensibility  -  A  minimal  change  in  concept  results 
in  a  similar  small  change  in  a  specification. 

The  rigorous  underlying  mathematics  for  algebras  satisfy 
the  formality  criteria  and  the  axioms  restrict  the  amount  or~ 
information  required  to  explain  desired  behavior,  thus 
satisfying  minimality.  Also,  it  appears  tnat  any  desired 
change  in  behavior  requires  a  minimum  of  additional  axioms 
or  minor  modifications  to  the  existing  ones.  As  for  applica- 
bility, algebraic  specifications  are  being  used  for  abstract 
machines,  data  types,  and  programming  languages,  which 
indicates  a  wide  range  of  applications. 
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Algebras,  in  Liskov  and  Zille's  opinion,  satisfied  all 
of    the    above   criteria  except    coniprehensibilty   and   cons tract - 

ability.  These  deficiencies  can  be  reduced  to  a  manageable 
level.  The  following  proposed  language,  Speclang ,  will  mini- 
mize these  problem  areas.  In  this  chapter,  it  will  be  sho*i:\ 
that  a  complex  specification  car  Le  modularize!;  broken  into 
smaller         units  which         enhance  cons tructabiiity         an  :1 

compr ehensibilit y . 

There  are  many  underlying  issues  involved  in  asin^  alge- 
bras for  specifications  which  nave  not  been  resolved. 
Issues  such  as  proving  specifications  correct,  infinite 
versus  finite  specifications,  implementation  and  ot-i<-r 
complex  issues  will  net  be  addressed.  The  following  sectj ons 
are  to  familiarize  t  lit  reader  with  the  grammar  ioi  Speciang, 
parts  of  a  specification  produced  from  the  Speslang  grammar 
and   a   brief   explanation   of    the    uses    of   the    various    parts. 

A.       SPECLANG    GRAMMAR 

Before  presenting  the  various  parts  of  a  specification 
constructed  from  Sjeclanj,  an  introduction  to  the  grammar  is 
presented.  Appendix  A  contains  the  complete  grammar  foi 
Speclang.  The  production  rules  are  written  in  a  modified 
Eackus-Naur  (3NF)  notation.  The  meta-symbols  in  the  produc- 
tion rules  are  used  to  form  the  construe  ti  on  or  a  specx.i-.;.- 
tion      and   do      not    appear      in    the      final    specification.  An 

explanation  of  the  meta-symbols  used  to  produce  terminal 
strings    in    the    grammar    are   as    fellows: 

<  >  -  A  name  enclosed  by  pointed  brackets  indicates  a 
non-terminal   in    the    grammar. 


»   i  _ 


Strings  in  gaotes  indicate  terminal  strings. 


(   )    -  Rounded  brackets  indicate   the  scope  of   a  modifier 
symbol. 
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*  -  The  Kleene  closure  modifier  may  follow  either  rounded 
brackets,  terminals  or  non-ter minais .  It  means  that  zero  ur 
more    of    the    expressions,       terminals      or    non-terminals    ray    be 

produced . 

+  -  The  alternation  modifier  is  used  like  the  Kleene  modi- 
fier. It  means  that  one  or  more  of  the  expressions, 
terminals    or   non-terminals    may    he    produced. 

|  -  The  selection  modifier  indicates  a  choice  of  non- 
terminals, terminals  or  expressions.  It  is  used  between  two 
choices.  In  order  to  clarify  the  selection,  rounded  brackets 
enclose    the    select  ion. 

?  -  The  option  modifier  indicates  that  the  terminal, 
non-terminal,    or    expression    is    optional   and    can    be    excluded. 

->    -    The      production    symbol    indicates    what      the    non-terminal 

on    the    left    hand   side  can    produce. 

A  production  rule  consists  cf  a  non- terminal  followed  b-j 
a  production  symbol  followed  by  an  expression.  An  expression 
is  comprised  of  terminals,  non- terminals,  modifying  symbols, 
and    may    include    other  expressions.       The    following    production 

rule  will  be  used  as  an  example  througnout  the  remainder  of 
the    thesis: 

<moduie_spec>    ->    <spec_header > 

(<newline><indent><param_bIoc k>)  ? 

<newline><indent><spec_body> 

This  rule  defines  a  srecif icaticn  module.  The  module  would 
begin  with  a  specification  header  followed  by  an  optional 
expression  that  contains  a  carriage  return,  indentation  and 
a  parameter  block.  Because  it  is  an  optional  expression,  it 
may       be    omitted.  After    the      expression,       another      carriage 

return  and  indentation  occurs  followed  by  a  specification 
body . 
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Che  grammar  for  Speciang  includes  indentation  and 
carriage  returns  to  permit  a  formatting  of  the  specifica- 
tion. This  was  done  to  create  a  standard  xormat  which  will, 
hopefully,    increase    the   readability    of    a    specification. 

A  specification  is  complete  when  all  the  strings  in  the 
specification  are  terminal  strings.  This  is  accomplished  by 
starting  with  a  nonterminal  and  substituting  the  expression 
appearing  on  the  right  hand  side  of  its  production  rule.  The 
remaining  nonterminals  are  then  substituted  until  all  the 
strings   are   terminal    strings.  For    example,      starting    with 

the  nonterminal  <module_spec>  and  substituting  the  right 
hand    part  of   its   rule  results   in   the    following: 

<spec_header>    (<newline><indent><param_block>) ? 

<newline><indent><spec_body> 

The    rule   for   a    specification    header    is: 

<spec_header>   ->    'SPEC1    <spec_id>    'IS' 

Its  right  hand  side  is  substituted  into  the  right  hand  side 
of    the   above   strings    to   produce: 

'SPEC    <spec_id>    *IS'     (<new_line>    <inlent>    <param_biock>) ? 
<newline>    <indent>    <spec_body> 

<newline>  and  <indent>  can  be  interpreted  as  carriage  return 
and  a  tab  respectively,  except  when  it  followed  by  a 
modifier,    and    make    the   developing   specification    appear    as: 

SPEC    <spec_id>    IS     (<newline><indent>< param_bl ock>) ? 
<spec_body> 

In  the  lexical  grammar  for  Speciang,  <indent>  is  treated 
either  as  one  or  more  tabs  or  spaces.  This  was  done  to 
permit  the  degree  of  indentation  a  specifier  desires.  Once  a 
indentation  has  been  selected,  it  should  be  continued 
throughout    the    specification.       For    instance,         if    one    tab   is 
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used  to  indent  a  line,  then  every  time  indent  is  encountered 
one    tab    should    be    used. 

Since  <par am_block>  is  optional  it  can  be  eliminated  to 
prod  uce : 

SPEC    <spec_id>    15 
<spec_  body> 

The  substitutions  are  continued  until  ail  strings  are 
composed   of    terminal    characters. 

The  first  nonterminal  string  in  Speclanc  is  <comp_spec> . 
This    denotes   a    complete    specification.  .\s    mentioned    in    the 

previous  section  a  specification  developed  from  Speclang  is 
made  up  of  modules.  Each  module  in  itself  is  a  specifica- 
tion. To  reflect  this  the  right  hand  side  of  the  production 
rule    for   <comp_spec>    is    <moduie_spec>+.  In    other    words,       a 

complete  specification  is  made  up  of  one  or  more 
specification   modules. 

B.       PAETS    OF    A    SPECIFICATION 

As  mentioned  in  the  previous  section,  a  complete  speci- 
fication is  made  up  of  one  or  more  specification  modules. 
Each  specification  module  is  an  algebraic  specification, 
which  can  be  viewed  as  a  sutspecif ication  of  the  complete 
specification,  and  has  three  distinct  parts  -  header,  signa- 
ture, and  axiom  parts.  Each  specification  module  is  either 
"primitive",         "extended"      or       "parameterized".  Primitive 

modules  do  not  import  other  specif  ication  modules  wr.iie 
extended  modules  do  import  other  specification  modules  to 
create    a      new    specification.  "Parameterized"    modules      art 

used  to  minimize  a  specification  and  can  be  either  primitive 
or    extended. 

A  specification  is  started  with  primitive  modules.  These 
modules      are      used       to      create      other      modules      through      the 
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techniques  described  in  the  next  sections.  Iha  last  speci- 
fication module  defined  in  a  complete  specification,  in 
effect,  consists  of  all  the  other  specification  modules 
since  it  is  built  frcm  the  previous  modules.  The  following 
section  describes  and  discusses  each  part  of  a  s;  ecif ic<ition 
module. 

1 .   Header 

The  header  identifies  the  name  of  the  specification 
and  sonetimes  contains  a  "modifier".  "Primitive"  ;uodui<vS  in 
Speclang   contain    no    modifiers    and   the    format    is    as    follows: 

SPEC    <spec_id>    IS 

{signature    part} 
[axiom    part} 

<spec_id>  is  a  slot  for  the  particular  name  of  that 
declared  specification.  The  body  oz  the  specif  icat  xon,  which 
contains  the  syntactic  and  semantic  part,  follows  underneath 
tne  header.  When  used,  the  modifier  is  directly  under  the 
header.  Its  purpose  is  to  iinpcrt  other  specifications  into 
the      declared    specification.  The    modifier      is    the      primary 

method  used  to  combat  the  complexity  of  an  algebraic  speci- 
fication. It  will  be  presented  after  the  other  [arts  of  the 
specification    are   introduced. 

2  •       Sig^na t  ur  e    Part 

The  signature  part  of  an  algebraic  specification 
contains  the  declarations  for  sorts  and  operators  and 
defines  the  format  and  composition  of  the  operators.  It 
corresponds   to    the    signatures    discussed    in    chapter    two. 

a.       Sort    Declarations 

In   Speclang,    the    format    for    declaring    sorts    is: 

SPEC   <spec_id>   IS 
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SORTS 

<sor  t_id> ; 
<sor t_id> ; 

<sort_id>  is  the  slot  for  a  particular  sort 
name.  As  explained  in  the  previous  chapter,  the  sort  will 
identify  the  carrier  (s)  used  in  the  operators.  All  of  , the 
sorts  declared  under  the  header  SORTS  define  the  sort  set. 

b-   Operators  Declaration 

The  operators  declaration  can  contain  up  to  four 
different  t_ypes  of  declarations: 

1 .  Primitive 

2.  Derived 

3 .  Hidden 

4 .  Error 

These  operator  type  names  are  used  as  headers  to 
each  group  of  operators  declared  in  Specianj.  The  basic 
format    for   an    operator   is: 

<op_id>    :    <sort_id>,    <sort_id>    ...    ->    <sort_id> 

An  operation,  as  explained  in  chapter  II,  can 
map  zero  or  more  elements  from  a  carrier  set (s)  identified 
by      the      sort      name(s)  to    an      element      of      a      carrier      set 

identified    by    the    sort    name. 

A  specification  with  sorts  arid  operators  would 
appear    as   follows: 

SPEC    <identifier>    IS 
SORT 

<sor t_id> ; 
OPERATIONS 

PRIMITIVE 

<op_id>:->    <sort_id> ; 

<op_id> : <sort_id>,<sort_ii>    ->    <sort_id>; 
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HIDDEN 

<o^_id>, 

ERF.  OH 

<op_id> 
DERIVED 

<oJj_id> 


<scrt_id>    ->    <sort_id>; 


<sort_id>    ->    <sort_id>; 


<sort    id>    ->    <sort    id> 


(1)       primitive   Operators.  Primitive    operators 

are  newly  defined  operators  and  cannot  b3  constructed  iron 
any  other  operators  such  as  the  derived  operators  described 
next.  Primitive   operators      may    involve      sorts    from      other 

specification  modules  and  usually  contain  at  least  one  sort 
from    the   specification   in    which    they    are    leclared. 


(2) 


Derived  Operators. 


Derived   operators  are 


operators  which  can  be  produced   from  other  operators.   Ihey 
are   declared  so   the  implementcr   of   the  specification  is 


aware  that  their  existence  is   rot  essential. 


rci.  1  ilj  l  J.i  ce 


in  the  boolean  specification,  if  the  "not",  "and"  ana  "or" 
operators  are  defined,  it  is  not  necessary  to  include  an 
"implies"  operator  since  in  predicate  logic  "implies"  is 
equivalent  to  "not"  A  "and"  5-  The  benefit  in  having  a 
derived  operator,  such  as  "implies",  is  to  minimize  the 
specification  and,  in  many  cases,  make  the  specification 
more  comprehensible.  In  the  boolean  example,  "implies"  is  a 
well  understood  operator  and  using  it  xn  other  specification 
modules  will  make  the  modules  mere  readable  than  if  a  combi- 
nation of  "not"  and  "or"  were  used.  "implies"  would  be 
declared  under  the  DERIVED  header. 

(3)  R££2£  22££ator£.  -"e  proper  han&linj  of 
errors  is  crucial  tc  a  specification.  However,  it  is 
frequently  the  case  that  specifications  for  languages,  data 
types,  programs,  etc.  do  not  precisely  define  what  should 
happen  when  an  error  is  encountered.  This  is  carte  blanche 
for  the  impiementor  to  do  what  he  thinks  is  appropriate.   In 
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permit  tin 


bizari 


tne   worst   cases,    nothing  is   uone, 
consequences. 

A  specification  should  address  those 
circumstances  where  the  operator  may  not  make  sense  on  the 
operands  and  define  precisely  how  to  handle  them.  for 
example,  in  the  specification  for  a  data  type 
integers,  the  sorts  and  operators  would  be  as  foilovs 

SPEC  Stack  IS 
SORIS 

int ; 
stack ; 
OPERATIONS 

PRIMITIVE 

new :  s  tack ; 

push:  int,  stack  ->  stack; 

pop:  stack  ->  stack; 


top :  sta 


ck  ->  int. ; 


The  "new"  operator  creates  an  empty  stack 
and  the  "push"  and  "pop"  operator  behave  as  would  be 
expected.  The  "top"  operator  allows  the  user  to  view  the  top 
element  of  the  stack. 

Problems  occur  when  a  user  attempts  to 
"pop"  a  "new"  stack  or  view  the  first  element  of  a  "new" 
stack-  These  are  valid  operators  since  "new"  returns  a  stack 
and  the  "pop"  and  "top"  operators  are  defined  on  a  stack. 

It  would  seem  reasonable  to  introduce  a 
value  "error"  to  each  carrier  set  to  define  error  condi- 
tions. Guttag  [ Ref .  3]  proposed  this  approach.  The  result 
would  be  equations  which  specify  what  are  error  conditions. 
Axioms  pop  (new)  =  error  and  top  (new)  =  error  would  seemingly 
resolve  the  problem.  Guttag  also  required  equations  which 
defined  the  propagation  of  errors.  Therefore  pus h (error ,s)  = 
error  and  push {n, err  or)  =  error  would  be  introduced  into  the 
specification. 
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Easel  has  demonstrated  the  inadequacy  or 
this  approach  [Eef.  5].  Iha  valid  equations 
top  (push  (n,  error )  )  =  n  and  top  {push  (n, error)  )  =  error  can  be 
produced  from  the  axioms  which  imply  n  =  error  for  any  n. 

The  approach  adopted  in  Spp.clang  is  the 
one  used  ty  Fasel  and  developed  by  Goguer.  [Ref.  2].  This 
involves  introducing  error  operators  into  the  specification. 
These  operators  will  produce  error  messages.  In  the  stack 
operator,  we  would  define  error  operators  "topnev1  a;,  d 
"underflow"  which  produce  carrier  values  integer  and  stack 
respectively  and  also  generate  error  messages.  In  Speclang, 
the  error  operator  will  be  declared  under  the  error  ope  cat or 
title.  Using  the  stack  specification,  the  declaration  would 
be  as  follows: 

SPEC  Stack  IS 
SORT 

int ; 
stack ; 
OPERATIONS 

PRIMITIVE 

new:  ->  stack; 

push:  int,  stack  ->  stick;        • 
pop:  stack  ->  stack; 
top:  stack  ->  int; 
ERROR 

topnew:  ->  int; 
underflow:  ->  stack; 

The  axiom  portion  of  the  specification 
would  use  these  operators  to  define  error  conditions. 

(4)  Hidden  Operators.  iJnf ortunately,  it  is 
not  always  possible  to  have  just  operators  for  the  user. 
Some  operators  are  required  in  order  to  define  the  user 
operators.     Majster   demonstrates    this    with   a    stack 
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specification    which      includes    opt raters    th 


<—   L.         -   X  X  O  w 


to  view  any  element  of  the  stack.  without  disturbing  the 
stack.  [Eef.  6].  In  order  to  define  these  operators,  it  is 
necessary  to  define  a  "current  position"  which  point  to  a 
particular  element  in  the  stack,  not  necessarily  the  top 
element-  The  new  operators  are  "down"  which  moves  :he 
current  position  down  one  element  in  the  stack,  "return-' 
which  moves  the  current  position  to  the  top  of  the  staoA, 
and  "read"  which  will  give  the  value  of  the  element  at  which 
the  current  position  is  pointing.  Push,  por  and  top  can  only 
he  done  when  the  current  position  is  on  the  top  element. 
Using  just  the  operators  availatie  to  the  user,  it  appears 
that  an  infinite  numier  of  equations  are  re^uxred  to  define 
the  meaning  of  reading  each  element  of  the  stack  (if  the 
stack  is  considered  an  infinite  specif icat ion) .  The 
following  are  just  a  sample  of  the  equations  required: 

read  (push  (nO,  L)  =  nO 
read  (down  (push  (nO,  push  (n  1,  L)  ))  )  =  nl 
read  (down  (down  (push  (nO,  push  (nl,  push  (n2  ,L)  ))}}  )  =  n2 

Enumerating  ail  the  required  equations  is 
not  particularly  enlightening  for  the  implement  or  and  is  a 
gross  violation  of  liskov  and  Ziiies  minimality  criteria. 
To  solve  this  problem,  hidden  operators  are  introduced 
[fief.  7].  In  Majster's  stack,  lasei  proposed  using  a  hidden 
operator  "append".  Append  adds  a  new  element  to  the  top  of 
the  stack  without  changing  the  current  position.  If  the 
current  position  is  at  the  top  of  the  stack  then  append  has 
the  same  effect  as  push  followed  by  down: 

append  (n, new)  =  dewn  (push  (n,  new) 
append (n2 , push (n1, L)  )  =  down (pusn (n2, push (n 1 , L)  )  ) 

If  the  current  position  is  other  than  the 
top,  then  axioms  would  show  that  appending  is  unattached  to 
the  dewn  operator: 
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append  (n,  down  (L)  )  =  down (append  (n,L) ) 
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operator    can    then   be      defined    in 


terras   of    the   read  and   push   operators: 

read  (push  (n  ,L)  )     =    n 
read  (append  (a,  I))     =    read^L) 

Append  would  rot  ue  an.  operator  available 
to  the  user.  Its  creation  was  to  allow  a  finite  specifica- 
tion of  an  otherwise  infinite  specification.  Hidden  opera- 
tors like  append  would  be  declared  under  the  header  HID£ZN 
to    alert   the   specifier    of    its    special    use. 

Hidden  operators  present  problems  when 
overused.  In  particular,  they  suggest  an  implementation 
[Bef.  5].  The  append  operator  is  an  example  of  this.  The 
read  operator  problem  may  be  solved  in  ways  other  than  using 
append    that    is    less    suggestive    in    an    implementation. 

In  Spec  1  an v;,,  hidden  operators  are  declared 
under    the    "HIDDEN"    header. 

3.      Axiom   Part 

The  axiom  part  implicitly  describes  the  behavior  o£ 
the  previously  declared  operators.  It  is  the  most  difficult 
portion  of  a  specification  to  construct;  developing  the 
axioms  tc  reflect  only  the  desired  behavior  and  no  more  is 
tricky. 

In  Speclang,  the  equations  which  define  operator 
behavior  are  placed  below  the  header  "AX1G.V*.  The  variables 
used  in  the  operator  are  assumed  to  be  of  sort  types  ised  in 
the  declaration  of  the  operator.  The  format  for  axioms  is 
as  follows: 

SPEC  <spec_id>  IS 
SORTS 

sort  1 ; 

OPERATIONS 
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PRIMITIVE 

op1     :    scrt1->    sort1.; 
AXIOMS 

of  1  (x  1)     =    x2; 

The  equations  are  coapsed  of  a  left  side  and  a 
right  sice  separated  by  an  equal  sign.  The  equal  sign  does 
not  mean  the  two  sides  are  equal.  It  signifies  that  the 
terms  that  are  produced  from  the  operations  on  each  side  are 
in  the  same  equivalence  class.  Although  this  is  an  important 
concept  for  the  underlying  theory  of  algebraic  specifica- 
tions/ it  is  not  vital  to  the  person  developing  a  specifica- 
tion. Another  way  of  viewing  equations  is  that  each  operator 
is  defined  by  an  equation  that  siiows  wnat  Happens  when  the 
operator  is  applied.  For  example,  in  defining  the  "push;' 
operator  on  a  stack  S,  we  would  want  to  show  that  for  any 
element  e,  push  (S,e)  produces  a  stack,  with  e  on  top.  The 
specifier  should  know  that  the  top  of  a  stack  is  also 
related  to  the  "pop"  operator.  The  solution  then  in  defining 
"push"  is  to  relate  it  to  the  "top"  operator  as  follows: 

pop (push  (e  ,3) )     -    e 

The  implicit  definition  «of  behavior  through  alge- 
braic axioms  provides  independence  from*  implementation  but 
also  creates  problems  in  constructing  a  specification. 

^  •   Specla  ng  Modifiers 

When  developing  a  complex  program,  a  programmer  will 
modularize  functions.  The  benefits  are  a  more  readable 
program  and  the  program  is  easier  to  develop  and  maintain. 
An  algebraic  specification  using  Speclang  also  car.  be 
developed  this  way. 

Burstall  and  Goguen  [Ref.  8]  presented  a  structured 
language   which   effectively   breaks   a   specification   into 
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.smaller        ir.ore      manageable        units.  The      language        uses 

"theory_iui iding "  inodiiieis  which  permit  the  specilxer  to 
modify    previous    specifications.  Fasel    used      their    theory- 

building  modifiers  to  develop  his  specification  of  a 
program.  The  proposed  modifiers  to  accomplish  this  were 
combine,  induce,  extend  and  derive.  Speclang  uses  only  the 
extend    modifier    to    create   specifications. 

The  extend  modifier  adds  new  operators,  equations 
and    sometimes      sorts    to    a   specification.  Furthermore,       the 

extend  iaodifier  allows  the  specifier  to  combine  two  or  nore 
imported  specifications  to  create  the  hew  specification. 
Fhen  two  or  more  specifications  are  combined,  all  of  their 
sorts,  operators,  and  axioms  are  lumped  together  to  form  the 
new  specification;  this  method  is  a  shorthand  way  of 
defining  the  sorts,  operations,  and  axioms  which  minimize 
the    specification. 

In  order  to  show  the  use  of  the  extend  modifier 
without  combining,  Fasel 's  example  of  the  Natural 
specification   is    presented: 

SPEC    Natural    IS 

SORTS 

nat  ;• 

OPERATIONS  ' 

i 

zero:->    nat  ; 
succ:    nat    ->   nat; 

We  can  extend  the  specification  with  addition  and 
multiplication    to    create   a    new    specification    Natplus: 

SPEC    Natplus    IS 
EXTEND 

Natural  ; 
WITH 

OPERATIONS 

PRIMITIVE 
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add:    n a  t , na  t    - >    na t ; 

mult:    nat,nat->    nat; 
AXIOMS 

add  (n,  0 )    =    n ; 

add(succ(ra)  ,n)     =    succ  (add  (n,m)  )  ; 

mult  (0  ,  n)     ~    0  ; 

The  exterri  modifier  draws  in  all  the  operators, 
axioms  and  sorts  from  the  specification  name  following 
extend  and  in  this  case  from  Natural.  Additional  sorts, 
operators,  and  axioms  are  included  following  the  heading 
"WITH". 

If  the  extend  modifier  ws  used  to  combine  specifi- 
cations as  well  as  include  new  sorts,  operations,  an: 
axioms,  then  Natplus  could  have  been  extended  with  specifi- 
cations Boolean  and  Natural  to  produce  the  following 
specification: 

SPEC    Natplus    IS 
EXTEND 

Boolean ; 
Natural ; 
WITH 

OPERATIONS 
PRIMITIVE 

add:    nat , nat- >    nat; 
multiply:    nat, nat    ->    booi; 
egualto:    nat, nat    ->    haul; 
if_then_els e:    bool,nat,nat    ->    nat; 
AXIOMS 

add  (n,  0)     =    n; 

add  (succ  (m)  ,  n)     =    succ  (add  (n  ,  a)  )  ; 

multiply  (0  ,  n)     =0; 

multiply  (n,  succ  (m)  )     = 

add(n,  multiply  (n,m)  )  ; 
egualto  (0,succ  (m)  )     =    false; 
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equaito  (0,  G)     =    true; 
equaito (m, m)     =    true; 
if_then_else (T  ,v  1,  v2) 
if_then_eise  (P  #v1,  v2j 


vl; 

v2; 


Jn  this  case  we  have  two  specifications,  Boolean  and 
Natural,  which  are  used  to  define  the  Natplus  specification.. 
All  of  the  specifications  declared  by  tha  identifiers 
between  "EXTEND"  and  "WITH"  are  combined  to  produce  the  nev 
specification.  In  addition,  new  sorts,  operators  and  equa- 
tions are  defined  on  the  corbined  specification,  and  are 
declared    following    "WITH". 

Although  the  Natplus  specification  could  have  beer; 
easily  defined  without  the  extend  modifier,  a  iarjer,  core 
complex  specification  would  be  difficult  to  read  and  picb- 
ably  impossible  to  understand.  For  example,  the  acstrdct 
machine  specification  described  in  chapter  I  has  one  speci- 
fication module  which  represents  the  final  specification. 
Its  extend  modifier  combines  four  other  specification 
modules  and  extends  them  with  approximately  one  hundred 
other  operators  and  seventy  equations.  If  this  machine  -was 
described  without  the  extend  aodifier,  then  each  of  the 
combined  specification's  sorts,  operators,  and  axioms  would 
have  to  be  included  in  the  specif  ica  tion .  Sines  each  .:"  the 
combined      specifications   were       also    extended,  ^a.c'rl    ci       t**e 

specifications  imported  to  create  them  would  also  be 
included.  The  result  would  be  a  specification  containing 
hundreds         of         operators         and         equations,  makinu         the 

specification    incomprehensible. 

Before  a  specification  can  use  another  specific ataon 
in  the  modifier,  the  specification  beinj  imported  must  have 
already  been  declared.  In  the  above  example,  Natplus, 
Boolean  and  Natural,  would  have  already  been  declared  in  the 
complete   specif ica ticn. 
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5-   P ar_a me t_ erized  [iodules 

One  method  of  minimizing  a  specification  is  through 
the  use  of  parameterized  modules.  Goguen  suggested  this 
technique  and  Ganzinger  [Sef.  9]  explored  it  in  depth.  Zhe 
basic  concept  is  to  use  a  procedure  like  spacif  icatioii  to 
create  a  new  specification.  This  is  a  particularly  useful 
technique  when  many  specif icaticns  tend  to  ;oe  repeated  .such 
as  in  the  case  of  a  list  of  integers,  characters,  real 
numbers,  etc.  Instead  of  a  specification  for  each  type  of 
element,  a  generic  template  would  be  used  to  describe  row  a 
list  of  a  particular  type  should  behave-  The  parameterized 
specification  for  lists  can  be  invoked  by  passing  the  speci- 
fication for  reals,  integers,  characters,  etc.  producing  an 
instantiation  of  the  parmeterized  specification  which  is  a 
new  specification. 

Many  issues  are  still  unresolved  in  parameterized 
specification  which  will  not  he  addressed  here  [Hef.  9], 
Eefore  using  parameterized  specifications  these  issues 
should  be  understood. 

The  parameterized  module  consists  of  two  primary 
parts.  These  are  the  parameter  block  and  the  specification 
block.  The  parameter  part  of  a  specification  defines  »'^.i± 
may  come  inside  a  parameterized  module  during  an  instantia- 
tion. An  instantiation  is  the  passing  of  an  actual 
specification  to  a   parameterized  specification. 

The  parameters  can  be  viewed  as  the  interface  to  the 
outside  module  which  is  invoicing  the  procedure.  It  consists 
of  sorts,  operators,  and  axioms  and  is  announced  by  the 
header  "PARAMETERS". 

The  specification  part  is  like  the  specification 
body  used  in  primitive  specification  modules.  It  consists 
of  sorts,  operators  and  axioms  and  is  declared  by  the  header 
"DEFINED  3Y". 


37 


When  the  parameterized  specificatioi.  is  invoked  the 
formal  parmeter's  sorts,  operators  and  axioms  are  replace! 
by  the  actual  parameters  passed  from  the  designated 
specification. 

In      Speclang,  the      format      for         a      parameterized 

specification   would    appear    as    fellows: 

SPEC    <identifier>    15 
PARAMETERS 
SORTS 

<sort_tody> ; 
OPERATIONS 

<op_body>; 
AXIOMS 

<axiom_body>; 
DEFINED    BY 
SORTS 

<sort_tody>  ; 
OPERATIONS 

'op_body> ; 
AXIOMS 

<axiow_boiy > ; 

Ganzinger  illustrated  parameterized  specifications 
by    using    the   list    example: 

SPEC    Lists    IS 
PARAMETERS 
ENRICH 

Boolean ; 
KITH 

SORTS 

elem  ; 
OPERATIONS 
PRIMITIVE 

equal:  elem/elem  ->  bool; 
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if-t Hen- else  :    booi, elem ,elem    ->    eleia ; 

AXIOMS 

equal(e,e)     =    true; 
DEFINED    BY 
SORTS 

list; 
OPERATIONS 
PRIMITIVE 

lempty:    ->    list ; 
isempty:    list    ->   IdoI; 
cone:    elem,list   ->    list; 
cdr:    list    ->    list; 

if- then-else  :    b col, list, list    •->    list; 
first:    list    ->    list; 
AXIOMS 

cdr (lempty)     =    lemjty; 
cdr  (cone  (e,l)  )     =    1; 
cdr(if_then_else  (1,11,12) ) 

=   if_then_else (b ,cdr  (11}  ,cir  (12) )  ; 
isempty  (lempty)     =    true; 
isempty  (cone (e, 1)  )    =    false; 
isempty  (if _ the n_ else (b, 11 , 12) 

=    if_then_else  (b,  isempty  (11)  ,  isempty  (12)  )  ; 
first (lempty , e)     =    e; 
f  irst  (cene  (e,  1 ;  ,  e  ')     =    e; 
first  (i f_ then _else(b,j.1,i2)  ,e) 
=    if _xhen_else  (b, first  (I1,ej  , first  (12, e)  ; 


JJj  U  O  -I.  » 1  J  J.  4-  -J 


This      parameterized    specification 
name    and      brackets    arcund    the       specification    which    is      to    be 
used    for   the   instantiation.  Therefore,       if    a   specification 

for    a    list      of    natural    numbers    was      desired,       Li sts  (Nu tur al) 
would    invoke      the    parameterized   specification    for       list.       In 
order      for        Lists       to      be        correctly      invoked,  the      Nat 
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specification  must  "match"  the  rorma.L  parameters  or  L-.sts. 
In  Speciang,  the  sorts  are  matched  under  the  header  "ACTUAL 
SORTS"  and  the  operators  are  matched  under  the  header 
"ACTUAL  OPERATIONS".  Under  each  of  these  headers  the  sorts 
and  operators  that  are  to  replace  the  formal  parameters  are 
positioned  to  the  left  of  an  "IS".  The  formal  parameters  the 
actual  parameters  are  replacing  are  positioned  to  the  right 
of  the  "IS".  In  Speciang,  the  matching  parameters  are 
announced  at  invocation.  Using  the  natural  numbers 
invocation,  it  would  appear  as  follows: 

Lists  (Natural) 
WBEBE 

ACTUAL    50ETS 

nat    IS   elem 

bool    IS    tool 
ACTUAL    OPERATIONS 

equal    IS    egual 

if _then_else   IS    if_then_else 

and    IS   and 

not    IS    not 

Note      that    the      parameterized      specification    has      an 

extend  field  in  the  parameter  bloc*..  When  this  occurs,  the 
parameterized  specification  must  be  invoked  with  sorts  and 
operators  that  also  match  the  specifications  that  were 
imported  by  the  extension.  In  the  List  example,  the  sorts 
and  operators  in  the  Boolean  specification  were  matched  in 
the    invocation. 
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IV.    SPECIFIC A TION    EDITOR. 

In  order  to  facilitate  writing  specifications,  a  syntax 
directed  editor  was  designed  to  format  a  s^'jcific^xGi: 
created  from  Speciang.  The  editor  is  based  upon  idci^;  ^roit 
Davis  [Ref.  10]  and  HacLennan  [Ref.  11].  .It  is  table  driver, 
in  that  a  grammar  is  input  and  parsed  into  separate  produc- 
tion rule  trees.  The  production  trees  are  then  i^e^  t<: 
create  a  specification  tree.  By  using  the  table  method, 
flexibility  is  gained  in  altering  the  grammar  without 
affecting      the    editor.  tfacLennan ' s      editor      and    the      idea 

presented  by  Davis  was  to  create  an  internal  tree  froL  the 
grammar  which  was  annotated;  the  tree  >.as  in  a  parked  r'ocir. 
which      could   be      used  to      generate    the      machine    code.  Tr..e 

Specification  Editor  presented  here  was  designed  to  create  a 
syntactically  correct  specification  and  to  mak^  the  inter- 
face with  the  user  simple  and  friendly.  The  internal  tree 
created  by  the  editor  is  not  annotated  as  prescribe  I  by 
Davis  and  MacLennan.  The  editor  could  be  modified  to  incor- 
porate annotations  which  could  transform  the  syntax  tree 
created  by  the  tree  to  an  annotated  tree.  A  -grammar,  grammar 
was  developed  for  the  parser  which  is  based  on  the  modified 
BNF    notation    presented    in    chapter    III. 

The  grammar  used  in  the  editor  is  tne  same  as  that  in 
appendix   A    except    for  the    following: 

1.  Comments    have    not   been    incorporated. 

2.  The  input  grammar  cannot  have  selection  involving 
expressions.  For  example,  the  following  production 
rule  would  not  be  acceptable  since  the  right  hand 
side   contains    an    expression    with    the    selection: 

<spec_block>->  (<param_call><cr><indent >)  J <spec_body>) 
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This  restriction  was  irpuoseu  for  two  reasons;  to 
force  a  clear  display  selection  and  to  reduce  the 
problems  involved  in  programming  the  recursive 
descent  parser.  This  restriction  is  not  severe  since 
the  right  hand  side  couid  be  replaced  with  a 
selection    such   as    <param_call>    creating    two    rules: 

<module>    ->    (<param_call> | <spec_body>) 

<param_call>    ->    <call_block>    <cr>    <indent> 

3.       The      rules    were      modified      to      reduce    th^       nuober     of 
selections   available.  For    example,         the    rule    for    a 

<n.odule_spec>    is    as    follows: 

<mod_spec>    ->   <spec_header><modif ieis>?<spec_body> 

This  was  combined  with  the  rule  for  <spec_header>  to 
create    a    rule: 

<module_s^ec>    ->     'SPEC    <spec_id>    'IS'    <indent> 
<cr><modifiers>?   <spec_bod}'> 

A.       AN    EDITING    SESSION 

This      section    will      describe   an      editing    session.  The 

editior  is  initiated  by  entering  the  name  of  the  editor,- 
Sreced.  A  prompt  appears  re^uestin-j  the  name  of  the  file 
where  the  user  had  stored  a  tree  from  a  previous  editing 
sess  ion . 

The  screen  is  cleared  and  the  first  production  rule's 
right  hand  side  is  displayed  on  the  screen  in  an  "unparsed" 
form.  The  video  is  then  reversed  oc  the  first  nonterminal  or 
modifier  which  an  incut  selection  can  effect.  Ail  of  the 
strings  which  are  displayed  in  reverse  video  are  referred  to 
as    the   selector    field. 

For  example,  if  <module_spec>  was  the  first  rule,  then 
the    display    would   be    as    depicted    in    Figure    4. 1    . 
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SPEC    <spec  id>    IS       (<param_bloc k>; ? 
<spec_fody> 


ITCBE:    ^spec    id? 

SELECTIONS:- 

s:    select   d:    selector    down       u:selector    up    q:    ^uit    edxi 

b:    cursor    up    tree    f:    cursor    down    tree 


Figure    4.1         Display   of    the    Rule   <module_spec> . 

In  this  instance,  the  video  ror  <spec_id>  would  be  reverse'! 
denoting  the  selector,  and  the  bottom  of  the  display  would 
show    the   selections    available. 

The  selector  is  directly  related  to  a  selection  pointer, 
sel_ptr,  which  points  to  a  node  in  the  specification  free 
being  edited.  The  ncde  at  which  the  sel_ptr  is  pointing  is 
referred  to  as  the  current  node.  The  current  node  is  shew:. 
at  the  bottom  of  the  display  following  "NODE:".  Depending 
on  the  current  node  a  number  of  different  selections  ar e 
available.  The  possible  selections  a  user  can  make  during  an 
editing    session    are    described    ir   the    following    sections. 

1  .       "s"    Selection 

If  "s"  is  selected  and  the  current  node  is  a  nonter- 
minal, the  node  is  replaced  by  the  production  rule  identi- 
fied by  that  nonterminal.  In  the  above  example,  if  <spec_id> 
is    selected,      then      the    rule   for    <spec_id>      is    inserted    into 
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the    abstract    specification    tree,    the    screen    is    updated,       and 
the    selector    is    advanced. 


SPEC    <spec  id>    IS     (<para m_blocK >) ?  J 

<spec_TLlock> 


SELECTIONS: 

s:select   d:seiector   down      u:selector    up    g:iu 

b:se!ector    up    tree  f:selector    down    tree 


"RCjJIT~^spec"I3?~      "  ! 

SELECTIONS:- 

s:seiect   d:selector    down      u:selector    up    j^iiit    edit 
b:selector    up    tree   f:    selector    down    tree' 


SPEC    <identifier>    IS 
<param  biock> 
<spec_Elock> 


Figure    4.2        Selection   of    a    Non-terminal. 

If  the  current  node  is  an  option  node,  then  the  "s" 
selection  will  inhibit  the  display  of  the  question  mark  and 
the  nonterminals/terminals  preceeding  the  modifier  will 
become    part   of       the    abstract    specification    tree.  A    sioiia. 
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result  occurs  when  the  current  node  is  a  selection  modifier. 
In  this  case,  all  selections  which  are  no  longer  needed 
along  with  the  selection  symbols  are  not  displayed  when  the 
desired    selection    is    made. 

figure  4.2  shows  the  tree  before  and  after  an  update 
where   <spec_i&>    and    <param_block>    were    seiecteu. 

2.  "i"    selection 

The  "i"  or  insert  selection  is  available  only  when 
the  current  node  is  an  identifier  nonterminal  designated  by 
<i dent if ier >.  When  this  selection  is  made,  the  portion  of 
the  screen  where  the  identifier  occupied  is  blanked.  The 
user  at  this  point  can  then  type  in  the  identifier  desired. 
The  input  characters  are  then  checked  to  ensure  correct 
lexical  grammar  for  identifiers.  If  the  input  character  is 
incorrect,  it  will  be  ignored  and  the  elitor  will  wait  foi 
another  input.  The  input  string  can  be  terminated  with  a  -~ 
input.  In  any  case  the  string  will  be  terminated  when  its 
length  exceeds  twenty  characters.  Aftar  terminating  the 
input  the  editor  updates  the  screen  and  advances  the 
selector. 

3.  "b"  and  "f"  Selections 

The  "b"  and  '.'£"  inputs  move  the  selector  up  and  down 
the  screen  respectively. 

Some  nodes  the  sel_ptr  stops  on  are  not  displayable. 
In  these  cases,  all  the  descendants  in  the  tree  that  are 
eligible  are  displayed  via  the  selector.  As  an  example,  if 
<module_spec>  is  the  current  node  then  aLi  of  the  displayed 
characters  in  figure  4.2  would  he  inverted  and  Cmodule_spec> 
would  be  displayed  at  the  bottom  of  the  screen  after 
"NODE:". 
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4.      "u"   and   "d"    Selections 


The  "a"  ana  "d"  selections  are  similar  to  the  "b" 
and  "f"  selections;  they  move  the  selector  up  and  down  the 
screen.  The  difference  is  that  the  "a"  and  "d"  selections 
will  move  to  the  next  displayable  node  on  the  screen.  This 
facilitates   moving    the    selector    on    the    screen. 

5.       "m"    Selection 

The  "m"  selection  is  used  when  the  current  node  is  a 


selection  modifier  node.   Since  the   "f",   "I", 


Hi 


"d" 


selector   into      a    modifier      node   subtree,         the    "  m"      c 


selector      movement       selections      will    not      alio,-'      moving      the 

c  "j  de- 
selection" key  was  created  sc  the  user  could  move  the 
selector  over  the  desired  selection.  If  the  selector  is  on 
the  last  selection  and  "a"  is  selected,  then  the  selector 
will    move   back      to    the   first    selection.  The    selector    will 

remain  in  the  selection  tree  until  either  a  selection  is 
made  or  the  user  makes  a  "j"  selection  to  jump  out  of  the 
selection. 


6.       "e"    Selection 


The  "e"  selection  allows  the  user  to  "erase"  the 
string  the  selector  is  on.  This  means  that  the  string  will 
no  longer  be  displayed  on  the  screen.  The  "e"  selection  is 
available  when  the  current  node  is  tne  option  node  or  a 
nondisplayed   nonterminal. 

If  the  selector  has  an  option  symbol  in  its  field, 
the  erase  selection  will  eliminate  the  option  symbol, 
brackets  if  displayed,  and  the  nonterminals  and  modifiers  in 
the  selectors  field.  In  figure  4.2  if  <paraa_biock>  was  not 
desired  and  the  selector  was  positioned  on  (<pdram_block>) ?, 
then    the   erase    selection    would    yield    the    following    display: 

SPEC    <identifier>    IS 
<spec_body> 
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"iien  the  node  indicated  at  the  bottom  of  the  iispiaj 
is  not  a  displayable  node,  the  erase  will  eliminate  all  of 
the  strings  of  the  screen  which  are  in  selector's  field  an  1 
replace    them    with    that   node. 

7.       "r"    Selection 

The  "r"  selection  is  used  to  replace  an  option  node 
in  the  display  or  a  selection  node.  In  the  previous  example 
for  erase,  if  the  sel_ptr  was  positioned  in  the  specifi.  ca- 
tion tree  so  that  the  option  may  be  resei^cted,  then  the  "r" 
selection  would  replace  the  option  tree  in  the  specification 
tree      and   the      display      would       Le    updated      accordingly.  A 

selector  would  not  be  visible  in  the  case  where  the  option 
was  previously  erased.  The  replace  field  at  the  bottom  of 
the  screen  would  indicate  the  option  to  be  inserted  into  the 
tree. 

In  the  case  that  the  option  or  selection  nas  been 
previously  made,  then  the  entire  portion  of  the  tree  iro.u 
the  option  or  selection  would  be  eliminated.  The  strings 
that  would  be  eliminated  are  in  the  selector's  field.  Fcr 
example,    if    the    specification    was    as    follows: 

SPEC    <identifier>    IS 

PARAMETERS 

<spec_Diock> 
DEFINED    3Y 

<spec_biock> 


and    the      current    node      was    the      "not"    displayed 
<param_block>? ,    then    a    "r"    selection    would    yield: 

SPEC    <identifier>    IS    (<param_block>) ? 
<spec_block> 


option    r.oae 
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B.        DESIGiN    OF    SPECED 

The  editor  was  written  in  Pascal  and  implemented  on  a 
Digital  Vax  11/780  under  the  VMS  operating  system.  The 
editing  session  described  in  the  preceeding  section  was  the 
objective   before    the    design    of    the    editor    started. 

The  design  of.  the  program  was  done  in  a  top-down  manner. 
The    three    primary    modules    are    as   follows: 

1.  Initialization 

2.  Main  body  loo^ 

3.  Termination  routine 

1  •   ^§:£ly.  Design  Decisions 

In  order  to  simplify  the  display,  certain  nontermi- 
nals are  treated  in  a  special  manner.  The  <indent>  and  <cr> 
nonterminals  are  immediately  interpreted  by  the  editor. 
These  nonterminals  mean  indent  and  carriage  return 
respectively. 

The  indent  nonterminal,  <indent>,  before  a  nonter- 
minal or  expression  means  that  the  nonterminal  and  its 
descendants  will  be  indented  ty  a  preset  tab  or  i;pr.ces  if  a 
carriage  return  follows. 

The  identifier  nonterminal,  <i len tif iLt> ,  is  treated 
as  a  slot  for  inputting  a  string  of  characters.  This  seems 
reasonable  since  all  grammars  reguire  identifiers.  The 
lexical  composition  cf  the  identifier  is  built  into  the 
editor. 

2  •   Initialization 

The  first  routine  called  by  the  main  program  is 
Initialization.  This  routine  in  turn  calls  a  routine  called 
opengrammar  to  input  the  production  rules  from  a  grammar 
file.  Cpengrammar  has  a  scanner  that  ^reprocesses  the  input 
rules  to  ensure  that  lexically  they  are  correct.   It  "'looks'' 
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for    a    bracketed    left    hand    side    cf    each    rule    ,      il    "->'',       and 
then    bracketed    strings,    quoted    strings    and    metasytibols.       ]"h« 
grammar    rules   are    put  into   a    record    structure    which    consists 
of    a    left   hand    side    and    a      right    hand  sice    of   the    production 
rules  . 

The   next      procedure    called      is   parsegrammar.  This 

routine  is  a  recursive  descent  parser.  The  parser  is  based 
on  a  II  ( 1)  grammar  grammar  used  to  construct  the  production 
rules.    The    grammar    grammar    for    the    parser    is   as    follows: 

<production_r ule>   ->  <noiiterwinal><rttie_body> 
<rule_body>   ->     ( (<nonterminal> |<expression>J  ( • *' j '+ '  I  '  ?' ) ?) 
<expression>    ->'  [•  ( <rule_body> |<ident_list>)  ' )  ' 
<ident_list>    ->    <nonterminal>     (' J ' <nonterminal>) + 

Each  production  rule  in  the  grammar  grammar  is 
mimicked  by  a  module  in  the  recursive  descent  parser.  Every 
production  rule  in  the  grammar  for  Speclang  is  parsed  into  a 
separate  production  rule  tree  which  describes  its  syntactic 
structure. 

figure  4.3  shows  an  abstract  production  rule  tree 
for    the    <module_spec>   production   rule. 

For  each  production  rule  tree  there  is  pointer  in  an 
array  of  pointers  to  locate  that  rule  tree.  The  rule  trees 
are  located  by  searching  the  array  for  the  root  with  a  name 
that  matches.  A  production  rule  tree  is  constructed  from 
records    which    have;    pointer    and    integer    fields   as    follows; 
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y  rammru-.es   = 


rtcori 

parent: array ( 1 .. 20)    of   character; 

len : inte  ger ; 

child  :  array  (  1 ..  30)     of    |  gr  ammr  ules; 
par_ptr: l^rammruies; 
ch_no : in  teger ; 
rtype : integer ; 
num_ch : integer j 
disp : boolean ; 
in:    integer; 
end 


<aodule_spec>    ->    'SPE 


C    <spec    ii>    'IS' 
(<± n  ue n t ; <c r >< p  ar  ac . _L  1  o c k > ) 

<indent><crXspec   hodv> 


<module_spec> 


SPEC        <spec_id>      <cr>      ?      <indent>      <cr>      <spec_body> 


EXP 


<cr><indent><parm_tlock> 


Figure    4-3        A   Production   Rule    Tree. 

The  "parent"  identifies  the  name  of  rule,  string,  or 
modifier.  The  field  after  parent,  "len",  contains  the 
length    of    the    parent    character      string.         This    feild    is    used 


in  outputtirg  the  string  on  the  screen.  The  "child"  array 
points  to  the  descendants  of  that  rule.  A  pointer  called 
"par_ptr"  points  to  the  parent  of  that  node.  This  pointer 
was  necessary  in  order  to  move  the  selection  pointer  around 
the  abstract  tree.  The  '''ch_no"  field  identifies  what  child 
number  that  record  node  is  of.  a  parent  record  node  whereas 
the  num_ch  field  indicates  the  lumber  of  children  that  nodes 
has.  The    ch_no      and   nua_ch      fields    were      also    created      to 

facilitate   selector    ncvement.  The    "In"    field    is      used    for 

the  display  screen.  field  tags  the  "type"  of  record  node. 
There    are   seven    types    of    nodes    as    shown    in    Table    I    . 


TABLE 

I 

Node 

T 

yp< 

2S 

TX£e 

Description 

1 

nonterminals 

2 

modifiers-?,*,     ,+ 

3 

terminal    strings 

n 

expression    node 

4 

identifier    strings 

6 

ALT    node 

7 

ignore    node 

The  node  type  has  an  effect  on  the  selections  available,  how 
the  tree  is  "unparsed"  for  display,  and  the  movement  of  the 
selection    pointer. 

After  the  rules  are  parsed  a  procedure,  get_tree, 
will  open  the  file  of  a  specification  tree  that  was  stored 
after    a      previous    editing    session,         if    the    user       inputs    the 
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name    of    the 


:iie. 


a    user    stored    tree 


is   not    supplied, 


the    initialization      routine    will      copy    the      first    production 
rule    tree   and    use    it    as    the    root    of    the    specification    tree. 

The  final  steps  of  the  initialization  routine  set  up 
the  display  for  an  editing  session.  k  pointer,  prog_ptr. 
will  he  set  to  point  at  the  root  node.  If  a  user  specified 
tree  is  available  then  the  'f^oq_^>tr  is  set  to  the  root  of 
that    specification    tree. 

The  next  step  is  to  cle^r  the  screen  and  call  a 
routine,  print_tree,  which  "unparses"  the  tree  to  produce 
the    display    on    the    screen. 

The  final  step  of  the  initialization  routine  assigns 
the  selection  pointer  to  the  first  selection  of  the  tree. 
If  the  initial  production  rule  vas  displayed 
tree    would    appear   as    follows: 

<comp_spec> 


the    ahstr.-ict 


J 


<sel_ptr>    >      + 


<indent><cr><module_spec> 


a.       Print    E;outine 

The  print  routine,  which  unparses  the  specifica- 
tion tree  being  developed  and  displays  it  on  the  screen, 
deserves  further  explanation  due  to  its  complexity.  It  is  a 
recursive  procedure  which  does  an  inorder-  traversal  of  the 
specification  tree  and,  as  it  visits  each  node,  will  respond 
according    to   that    node's    type. 
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Initially,  the  prog_ptr  is  passed  to  the  print 
routine  and  then  a  case  statement  determines  how  to  handle 
the  roct  node  and  ail  nodes  recursively  passed  to  it.  Since 
the  root  node  is  the  left  hand  side  of  the  first  production, 
it  is  not  displayed.  Instead,  it  treated  as  a  nondis player] 
nonterminal   node    which   is    explained    below. 

The  predominant  factor  as  to  whether  or  not  a 
node  parent's  field  is  to  be  displayed  is  the  record  boolean 
field  "disp".  Only  if  the  field  is  true  will  it  bo  output  to 
the    screen. 

Another  factor  for  drspiayability  is  the  line 
number  of  the  node.  Since  the  screen  can  only  displav  a 
small      fixed   number      of    lines       cf    the      specif ica tion    at      one 


..i    '*• ..  — 


time,  a  current  line  is  assigned  for  the  display  wn 
dictate  what  nodes  in  tue  specified tion  will  be  shown.  If  a 
node's  "in"  field  is  in  a  particular  value  range  of  the 
display  line  number  then  it  will  be  displayed.  Otherwise, 
even  if  the  disp  field  is  true,  it  will  not  be  displayed. 
For  example,  if  the  current  line  is  twenty,  then  all  the 
specification  nodes  whose  In  field  falls  in  the  range  twenty 
to  thirty  five  will  be  displayed. 

As  mentioned  before,  the  print  routine  responds 
to  a  node's  type  via  a  case  statement  which  has  seven  cases 
tuat  correspond  to  the  seven  node  types  in  Table  I. 

Case  one  handles  nonterminals.  This  case  checks 
initially  to  see  if  the  nonterminal  is  a  carriage  ceturn  or 
an  indent.  If  it  is  a  carriage  return,  the  screen  line 
number  is  incremented  and  the  selector  positioned  on  the 
next  line  of  the  screen.  If  the  nonterminal  is  an  indent 
symbol,  a  global  indent  counter  is ' incremented  by  one  and  an 
indent  flag  is  set.  This  mechanism  is  used  to  cause  the 
nonterminal  and  its  descendants  following  the  indentation  to 
be  indented. 
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Before  a  nonterminal  or  its  descendants  are 
displaced  on  the  screen/  a  glotai  flag  is  checked  :o  s^>^  if 
the  preceding  nonterminal  was  an  indentation.  If  it  was, 
then  the  global  flag  is  set  to  off  and  a  local  flag  is 
turned  on.  After  the  nonterminal  or  its  descendants  are 
displayed,  the  local  flay  is  checked.  If  the  flag  is  o:.,  tha 
number  of  immediately  preceeding  indentations  are  subtracted 
from  an  indentation  counter  and  the  local  flag  ds  turned 
off.  Using  this  method,  the  indentation  affects  only  the 
nonterminal  or  the  expression  following  it.  For  example,  if 
the    rule   for   <modu!e_spec>    was: 

<moduie_spec>    ->    SPEC    <spec_id>    IS 

(<indent><cr><param_blocA>) 1 
<ind€nt><cr><spec_block> 

The    initial   display    would    be    as    follows: 

SPEC    <spec_id>    IS     (<par am_bloc>>)  ? 
<spec_block> 

When  <param_block>  is  expanded  the  indentation  will  affect: 
all  of  its  descendants  so  that  the  display  would  arpear  as 
follows: 

SPEC    <spec_id>    IS 

PARAMETERS 

<spec_b!ock> 
DEFINED    3Y 

<spec_block> 

iiote  that  <spec_t!ock>  is  indected  by  two.  This  happened 
because  the  rule  for  <param_blocK>  has  an  <indent>  at  the 
end  and  the  rule  for  <modu!e_spec>  nas  an  <indent> 
preceeding      it.  If  <param_blcck>       was      eliminated,         then 

<spec_b!ock>    would    only    be    indented    by    one. 
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If  the  Qode  passed  to  the  print  routine  is  not  a 
carriage  return  or  indent,  then  the  boolean  field  "disp"  in 
tested  for  displayability.  If  the  field  is  true  taen  the 
node's  parent  field  is  written  to  the  screen.  If  the  nonter- 
minal is  not  to  be  displayed,  then  a  recursive  call  is  made 
to  the  print  routine  for  each  of  the  pointers  in  the  "child" 
field  of  that  node. 

Case  two  handles  all  the  modifier  nodes.  If  a 
selection  modifier  node  is  encountered  and  is  to  :  ■■ 
displayed,  the  print  routine  will  display  all  the  selec- 
tions and  place  the  "j"  symbol  between  the  choices.  All  th  :• 
other  modifier  nodes  will  have  a  recursive  call  to  the  print 
routine  on  their  descendants.  After  returning  from  the 
recursive  call,  the  node  is  checked  to  see  if  it  is  to  be 
displayed-  This  is  how  the  postfixing  of  tae  modifier 
symbols  is  accomplished. 

Case  three  handles  the  template  nodes.  These  are 
nodes  that  have  strings  that  are  required  in  the  grammar. 
For  example,  every  module  must  have  the  string  "SPEC"  and 
tne  string  "IS"  on  the  first  line.  These  nodes  have  no 
descendants  and  so  the  print  routine  will  not  make  any 
recursive  calls  on  the  descendants. 

Case  four  deals  with  expression  nodes.  An 
expression  node  is  used  to  point  to  tne  descendants; •  its 
only  function  is  to  allow  the  print  routine  to  make  recur- 
sive calls  on  each  descendant.  If  a  global  flag  is  set  in 
the  case  two  condition  indicating  the  expression  is  followed 
by  a  modifier,  tnen  brackets  surrounding  the  expression  will 
be  displayed. 

Case  five  prints  the  identifier  nodes.  These  ire 
terminal  strings  for  identifiers  an i  are  treated  like  the 
case  three  nodes. 

Case  six  deals  with  the  "ALT"  nodes.  This  node 
is  used  to  store  trees  such   as  options  and  selections  after 
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these  nodes  have  been  acted  or..  It  also  retains  the  Kleene 
and  alternation  trees.  Normally  the  ALT  node  has  two  descen- 
dant nodes.  The  left  one  is  for  the  branch  leading  to 
displayed  strings.  The  right  one  is  for  storing  the  option, 
selection,  Kleene  and  alternation  trees  or  it  may  point  to 
another  ALT  node.  The  print  routine  will  recursively  call 
each  of  the  children  nodes. 

Case  seven  is  the  ignore  case.  This  is  used  when 
the  node  and  its  descendants  are  to  be  ignored.  For  exacple, 
in  the  case  where  the  option  ncde  was  used  and  stored.  The 
option  expression  is  no  longer  desired  for  display  so  it  is 
given  a  type  seven. 

3  •   Main  3ody_  Loo£ 

The  editor,  after  initialization,  enters  a  loop  in 
the  main  program  body  which  inspects  the  type  node  at  which 
the  selection  pointer  is  pointing  and  calls  one  of  eight 
routines  to  handle  that  case.  The  routines  are  shown  in 
Table  II  . 

All  of  the  routines  which  handle  the  various  node 
types  are  essentially  constructed  the  same-  A  procedure, 
sho_slection,  is  called  in  each  routine  which  displays  the 
various  selections  available  in  taat  routine  at  the  bottom 
of  the  screen.  Zach  routine  then  enters  a  loop  which 
retrieves  the  input  from  the  terminal  and  deciphers  the 
input  via  a  case  statement.  If  an  invalid  character  is 
selected,  it  is  ignored  and  the  routine  loops  for  another 
input . 

The  following  sections  will  discuss  the  routines  in 
Table  II  with  the  exception  cf  the  first  section  which 
discusses  the  selector  movement  routines. 
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TABLE  II 
Routines  called  by  Main  Body  Loop 


Node 

Nonterminal 
? 

1 

+ 

ident  if ier 

ALT 

Rout 

me 

Id_repiace 

Option 

Selection 

Alternation 

Kleene 

Id_deselect 

altrep 

J 


a.   Selector  Movement  Routines 

There  are  four  routines  used  to  position  the 
selection  pointer  on  a  node  in  the  specification  tree  in 
concert  with  the  selector  on  the  screen.  They  each  corre- 
spond to  cne  of  the  four  selections,  "u",  "d",  ,{f:,#  and  i:L;!, 
available  in  all  the  routines  shown  in  Table  II  .  When  r'i'' 
or  "u"  inputs  are  received,  cne  of  two  routines  will  he 
called  to  move  selection  pointer  and  the  selector  to  the 
next  disp_layable  selection  either  down  or  up  u. u-a  screen; 
this  means  the  selection  pointer  will  be  at  a  node  that  is 
visible  on  the  display. 

The  "b"  or  "f"  inputs  move  the  selector  backward 
or  forward  to  any  node  in  the  specification  tree  that  is 
available  for  modification.  These  two  inputs  also  have  two 
separate  routines  which  move  the  selection  pointer  in  the 
tree.  Ihe  "b"  and  "f"  selections  allow  the  interior  nodes, 
which  are  not  displayed  on  the  screen,  to  be  available  ior 
alteration. 
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All  of  the  selector  .novement  c  ou  ti :.  -;  5  ire 
designed  so  that  they  will  not  position  the  selection 
pointer  on  "EXP"  nodes,  modifier  nodes  ,if  they  have  been 
erased  or  selected.  and  terminal  type  three  nodes  that 
contain  strings  usel  in  the  granmar.  Ihe  nondisplayed  modi- 
fier nodes  are  accessed  in  a  different  manner.  After  the 
selection  pointer  is  moved,  the  current  node  is  checked  to 
determine  if  it  is  on  the  screen.  If  it  is  not,  the  current 
screen  display  line  is  updated  to  position  that  node  in  the 
center  line  of  the  screen.  The  print  routine  is  then  called 
to    update   the    screen. 

b.       Replace    Routine 

The  replace  routine  acts  on  type  one  nonterminal 
nodes.  Two  general  cases  are  possible,  depending  on  whether 
the  node  is  displayed.  In  the  case  where  the  nonterminal  is 
displayed,  the  replace  routine  enables  the  user  to  add  to 
the  specification  tree  the  production  rule  tree  indicated  by 
the  nonterminal  node's  parent  field.  As  mentioned  in  the 
previous  section,  this  occurs  when  an  "s"  is  input.  Figure 
4.4  shows  the  specification  tree  before  and  after  an  "  s:'  is 
input  and  the  selection  pointer  is  at  <spec_id>  in  a 
specification    tree. 

Nhen  "s"  is  selected,  a  routine  called  clone 
locates  and  reproduces  the  the  production  rule  tree  for 
<spec_id>  and  returns  a  pointer  to  the  replace  routine.  Ihe 
replace  routine  then  attaches  the  rule  tree  to  the  specifi- 
cation tree.  The  <spec_id>  "disp"  field  is  then  set  to  false 
to    inhibit    its    display. 

It  is  possible  that  the  selection  pointer  is  at 
a  type  one  node  that  is  not  displayed;  its  disp  field  is  set 
to  false.  In  this  case,  the  displayabie  descendants  ars 
shown  in  the  selector's  field.  An  option  to  erase  is  then 
available   to   eliminate      all    the   descendants    ana      restore    the 
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<module_s pec> 


EXf 


<indent>    <cr>   <parani    block> 


<module_s pec> 


SPEC      <spec_id>        IS        ?         <indent>      <cr> 


<identif ier> 


<indent>    <cr>    <param    block> 


Figure    4.4        Selection    of   <spec_id>. 

not  displayed  nonterminal.  This  is  accomplish  ed  by  setting 
the  current  node's  child  pointer  to  nil  and  tht  disp  field 
to  true.  The  "NODE"  field  at  the  bottom  oz  the  screen  chows 
the    not    displayed    nonterminal. 

One  special  case  is  addressed  in  this  routine. 
This  is  the  case  when  the  selection  pointer  is  at  the  root 
of  the  specification  tree.  In  this  case,  the  first  produc- 
tion rule  tree  is  duplicated  and  substituted  when  the  "e" 
selection  is  made.  This  is  paramount  to  erasing  the  entire 
tree. 
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c .  j.d_repiace 

The  id_replace  routine  was  created  to  diic*  the 
user  to  input  directly  on  the  screen  the  identifier  names. 
This  routine  is  called  when  the  selection  node  type  is  on-?. 
and  the  nonterminal  is  <identif ier> .  When  an  "i"  is  input,  a 
case  statement  is  executed  which  determines  the  startiio 
position  on  the  screen  by  inspecting  the  current  node's 
posit  field.  A  blank  is  written  to  the  screen  starting  at 
that  position.  The  routine  then  takes  inputs  from  the 
terminal  and  places  them  in  that  node's  pared  field.  Each 
character  input  is  checked  for  [roper  lexical  grammar  and  is 
echoed  to  the  screen.  Invalid  characters  are  ignored.  The 
inputs  are  terminated  when  either  twenty  characters  have 
been    input    or    a    "$"    is   input. 

d.  Option    Routine 

The  option  routine  is  called  when  the  current 
node  is  type  two  and  the  parent  field  is  the  option  node 
modifier.  This  routine  will  allow  the  user  either  to  eras«= 
tiie  optional  expression  by  selecting  an  "e"  or  include  the 
expression    preceding    the    modifier    by    selecting    an    "s". 

•  When    the    option      is   selected    or    erased      an    "All" 

node  is  inserted  into  the  option  node's  position  m  the 
tree.  The  ALT  node  is  treated  as  if  it  only  has  two  chil- 
dren. The  right  child  wjlII  store  the  option  tree  so  that  if 
the  user  later  desires  to  reverse  his  previous  decision  ana 
include  it,  he  can  reinsert  the  option  tree  into  its  prior 
position  in  the  tree.  The  left  child  of  the  ALT  node  will  be 
nil  if  the  option  is  erased  or  will  contain  the  expression 
that  was  preceding  the  option  modifier  if  the  option  was 
selected.  Figure  4.5  shows  the  tree  before  and  after  the 
selection   of    the    <param_biock>    option. 
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<module_spec> 


V. 


.  sel    ptr 


SPEC    <spec_id>    IS 


1 


<indent>    <cr> 


EXF 


<indent>   <ci>   <param_block> 


<module_spec> 


SPEC      <spec_id>        IS      AIT      <indent>      <cr> 


sel_ptr >      EXP 


<indent><cr><param_fclock>      EXP 


<indent>    <cr>    <param_biock>         j 


Figure   4.5         Selection   of    the   Option    <param_block>. 

When  the  option  is  stored  in  the  right  child,  it 
is  assigned  a  type  seven  so  that  the  print  routine  will 
ignore    it   and   its    descendants. 

e.       Selection  Routine 

The  selection  routine  is  called  when  the  selec- 
tion   node   is   type    two   and      the    parent    field    is    the    selection 
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modifier.  Because  the  selector  down  or  selector  iL  routine 
can  not  access  the  descendants  cf  a  selection  node  or  option 
node,  the  selection  routine  wa£  written  to  permit  the  user 
to  designate  the  desired  string  by  using  the  Mm"  key  to 
position  the  selector  over  it.  Fhen  "m"  is  input  a  cast- 
statement  is  executed  which  will  loop  between  the  selections 
until  either  a  selection  is  made  or  a  "j"  is  entered  to  j  U121 
out  of  the  loop-  When  a  particular  nonterminal  is  selected 
the  routine  behaves  like  the  option  selection;  an  ALT  node 
is  inserted  for  the  selection  node  and  the  selection  node 
and  its  descendants  are  stored  in  the  right  child  of  the  All.' 
node. 


f.      Alternation    Routine 

The  alternation  routine  is  called  vh^i:  the 
selection  pointer  is  at  a  type  two  node  and  the  parent  is 
the  alternation  modifier.  The  routine  allows  the  user  to 
duplicate  the  expression  or  nonterminal  preceding  the  modi- 
fier. When  the  " s"  selection  is  made  an  ALT  node  is 
inserted  into  the  tree  at  the  alternation  position.  The  left 
child  points  to  a  cloned  expression  01  the  descendants  or 
the  alternation  modifier  and  the  right  child  points  to  the 
original  alternation  node  and  descendants.  Figure  n.t  snows 
the  tree  before  and  aft^r  a  selection.  Unlike  the  option 
and  selection  routines,  the  right  child  in  this  case  will 
not  Le  typed  seven  since  we  want  to  a^iow  the  u^tr  to  n»ake 
as  many  selections  as  he  would  desire.  After  the  user  has 
made  at  least  one  selection,  then  the  node  can  be  erased; 
the  alternation  routine  is  written  so  that  at  le^st  one 
selection  of  the  nonterminal  or  selection  must  he  male. 
This  is  accomplished  by  checking  if  the  alternation  modifier 
is  a  child  of  an  ALT  node.  If  alternation  modifier  is,  then 
a  selection  must  have  been  made  and  therefore  the  alterna- 
tion   tree    is   eligible   to    be      erased    from    the    display.  when 
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ar.    "en      i^    input,       the      routine   will    change      the    aiti  -  :.o;. 

node's    first    descendant    to    type   seven      ana    the    disp    Liei*     t  > 

false . 


i 


<axior,s> 


AXIOM 


+ 


EX? 


<indent>    <cr>    <a;;ioc    bodv> 


<axioms> 


AXIOM 


ALT 


<indent><cr><axiora    bodv>       EX? 


<inient>    <cr>    <axiom_body>       i 


Figure    4.6         Selection   of    an   Alternation    Expression. 


g.       Kleene    Routine 

The  kleene  routine  is  executed  if  the  current 
node  is  type  two  and  the  parent  field  is  the  kleene  modi- 
fier- Like  the  alternation  routine,  it  allocs  unlimited 
duplication    of    the    descendants    cf    the   modifier.       The    routine 
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the  same  as  the  alternation  routine  except  that  :.*: 
allows  the  user  to  erase  the  kleene  modifier  ana  its  descen- 
dants even  if  a  selection  has  net  been  made.  To  accomplish 
this,  the  kleene  node's  display  field  is  set  to  false  and 
the    first   descendant    is   set    to    type    seven. 

h-       Altrep    routine 

The  altrep  routine  is  called  when  the  selection 
pointer  is  on  an  ALT  node.  As  discussed  before,  the  ALT  node 
is  used  to  handle  cases  for  the  option,  selection,  alterna- 
tion, and  kleene  routines.  Consequently  the  altrep  routine 
handles  two  cases;  one  case  is  when  the  ALT  node  is  the 
result  of  action  taken  on  an  cption  or  selection  node  and 
the  other  case  is  when  the  ALT  node  is  the  result  of  action 
taken    on   an   alternation   or    kleere    node. 

If  the  ALT  node  was  the  result  of  action  taken 
on  an  option  or  selection  node  tnen  the  case  statement  will 
permit    the    user      to    erase    the    left    tree,  eliminate    the    ALT 

node  and  place  the  option  or  selection  tree  in  the  specifi- 
cation tree  in  its  former  position.  Figure  4.7  shows  the 
result  of  reseiecting  the  <param_block>  option  which  puts 
the    <param_block>    option    tree    in   its    previous   position. 

The  case  where  the  ALT  node  was  the  result  of 
action  on  an  alternation  or  kleene  node  has  two  subcases. 
Cue  case  is  where  the  ALT  node  proceeds  another  XL1  node 
such    as    follows: 

sel_ptr    >    ALT 


<sort    id> 


al: 


<sort    id> 


+ 


<sort    id> 
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<module_sj:ec> 

r  i 

SPEC      <spec_id>         IS       ALT      <indent>      <cz. 


EXP 


^7  \      \ 

<indent><cr><parara_tlock>      r.XP 


<indent>    <cr>    <parar._block> 


<module_spec> 


SPEC    <spec_id>    IS      ':      <indent>    <c:> 


I 


EX? 


<indent>    <cr>    <param_blocK > 


Figure   4.7        Reselecting    the    <param_block>    Option. 

In    this   instance,      a    selection    is    available    to   eliminate    the 
ALT    node,    its    left    child    and    all    of    the    left   child's    aesc-n- 
dants.         In    this    way    the      user    may    eliminate    selccticr s    :v..c. 
before. 

The    other   possibility      is    where   the    ALT       noda   is 
adjacent    to   a    kleene    or    alternation    node    as    follows: 
sel_ptr    >         ALT 

<sort_id>  ♦ 

<sort    id> 
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In  this  case,  t ae  selection  to  eliminate  the  ALT  is  avail- 
able and  if  the  kieene  or  alternation  node  has  been  erased, 
a  replace  selection  is  available  to  redisplay  the  kieene  01 
alternation  node  ana  its  descendants-  This  is  dene  by 
setting  the  alternation  or  Kieene  node's  first  descendant 
type    field    to   seven    and    the    disp   field   to    true. 

U -       Ter minat ion 

After  the  user  inputs  a  "q"  to  quit  the  editing 
session,  the  editor  exits  the  main  body  loop  and  then  calls 
a  termination  routine.  This  rcutine  may  call  two  different 
routines  depending  on  the  users  desires: 

1.  Store  Tree 

2.  Pretty  Print 

a.  Store  Tree 

This  recursive  routine  performs  an  inorder  trav- 
ersal of  the  specification  tree  to  store  the  fields  of  each 
node.  It  is  called  if  the  user  answers  yes  to  a  ironpt 
asking  if  he  wants  to  store  the  abstract  tree.  Fhen  the 
routine  is  entered,  a  file  is  opened  with  the  filename  input 
at  the  beginning  of  the  editing  session.  Each  node  of  the 
abstract  specification  tree  is  then  visited  and  its  fields 
stored  in  the  file. 

b.  Pretty  Print 

This  routine  is  called  when  the  user  answers  yes 
to  a  prompt  asking  if  he  desires  a  ^retty  print  rile  oi:  the 
abstract  tree.  This  file  will  he  an  unparsed  version  of  th^ 
abstract  specification  tree.  It  is  essentially  the  same 
routine  used  for  unparsing  and  displaying  the  tree  on  the 
screen,  except  this  routine  ignores  the  lire  number  used  :or 
display. 
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V.  5DHHABY 

Speclang  is  a  language  based  on  aljebras  which  i.as  thc- 
faciiities  lor  creating  formal  specifications  that  fit  the 
criteria  establisned  by  Liskov  and  Zilles.  Speciang  reduces 
the  complexity  of  a  specification,  and  makes  a  specification 
more  readable  and  easier  to  construct  b}  using  a  modular 
hierarchy;  module  specifications  are  bui^t  L\  importer j 
otner  specification  modules  through  the  extend  modifier. 
Parameterized  specifications  modules  help  to  iiiinimize  s 
specification  by  eliminating  redundant  s^ eoaficatron 
modules.  Futheruior  e,  indentations  and  carriage-  returns 
imbedded  in  the  grammar  help  to  promote  a  consistent  format 
between  specifications.  A  consistent  foradt  will  assist 
readers  of  the  specifications  developed  from  the  Speciang 
grammar. 

Because  there  are  many  unresolved  issues  in  using  alge- 
bras for  specifications  which  may  effect  the  format  and 
grammar  of  Speciang,  a  table  driven  syntax  directed  editor, 
Speced,  was  created  to  assist  the  specifier.  Its  purpose  is 
to  create  syntactically  correct  specifications.  Furthermore, 
the  design  of  the  editor  permits  the  user  to  easily  modify 
the  grammar. 
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APPENI)!!    A 
SPECLANG     GRAMMAR 

The      production        rules      are        written      in         a      modified 
Backus-Naur    (BNF)       notation.  An    explanation      of    the      r.eta- 

symbols  jsed  to  produce  terminal  strings  in  the  grammar  are 
as    follows: 

<  >  -  A  name  enclosed  by  pointed  brackets  indicates  a  non- 
terminal   in    the    grammar. 

1       '    -    Strings    in    quotes    indicate    terminal    strings. 

(      )  -   Rounded    brackets    indicate      the    scope    of       a    modifier 

symbol. 

*  -  The  Kleene  closure  modifier  may  follow  either  rounded 
brackets,  terminals  or  non-terminals.  It  means  that  zero  or 
more  of  the  expressions,  terminals  or  non-terminals  may  Le 
produced. 

+  -  The  alternation  modifier  is  used  like  the  Kleene  modi- 
fier. It  means  that  one  or  more  expressions,  terminals  or 
non- terminals    may    be    produced. 

1  -  The  selection  modifier  indicates  a  choice  of  non- 
terminals, terminals  or  expressions.  It  is  used  bet  veer,  two 
or  more  choices.  In  order  to  clarify  the  selection,  rounded 
brackets   must    enclose   the    selection. 

?  -  The  option  modifier  indicates  that  the  terminal,  non- 
terminal,   or   expression    is    optional    and    can    be    excluded. 

->  -  The  production  symbol  indicates  what  a  non-terminal  can 
prod  uce. 
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A  production  rale  consists  cf  a  non- terminal  followed  by 
a  production  symbol  followed  by  an  expression.  At  expression 
is  comprised  of  terminals,  non- terminals,  modifying  symbols, 
and    may    include    other   expressions. 

The  grammar  for  Speclang  includes  indentation  and 
carriage    returns    to    force    a    xor matting   of    the   specification. 

A  specification  is  complete  when  ail  the  strings  in  the 
specification  are  terminal  strings.  This  is  accomplished  lj 
starting  with  a  nonterminal  and  substituting  the  nonterminal 
which  are  on  the  right  hand  side  of  the  production  rule  for 
it.  The  remaining  nonterminals  are  then  substitute!  until 
ail  strings  are  terminal  strings.  For  example,  starting 
with  the  nonterminal  <spec_moduie>  and  substituting  the 
right    hand    part    of    the   rule    results    in    the    following: 

<spec_header>    <param_ tlock>?    <spec_body> 

The    rule   for   a    specification    header    is: 

<spec_header>    ->    *S2IC%    <spec_id>    'IS'    <new_iine>    <indent> 

It  right  hand  side  is  substituted  into  the  above  string  to 
produce : 

•SPEC'    <spec_id>    '15'    <new_line>    <indent>    <par am_block> : 

<spec_bcdy> 

<newline>  and  <indent>  are  interpreted  as  carriage  return 
and  a  tab  respectively,  except  when  they  are  in  an  expres- 
sion followed  by  a  modifier,  and  make  the  developing  specif- 
cation    appear   as: 

SPEC    <spec_id>    15 

<param_block>?    <spec_block> 

Since  <param_block>  is  optional  it  can  be  eliminated  to 
produce : 

SPEC   <spec_id>    IS 
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<spec_touy > 

The      substitutions      are      continued      until      all      strings      ire 

terminal  strings.  The  first  nonterminal  string  in  Speclang 
is  <comp_spec>.  This  denotes  a  complete  specification.  &s 
mentioned  in  the  previous  section  a  specification  developed 
from  Speclang  is  made  up  of  modules.  Each  module  in  itself 
is  a  specification.  To  reflect  this  the  right  hand  side  of 
the  production  rule  for  <comp_spec>  is  <module_spec>+.  In 
other  words,  a  complete  specification  is  made  ip  of  one  •>  : 
more    specification    modules. 

The    production    rules    are    as   follows: 

<compiete_spec>   ->    (<iiiodule_£pec><newiine><ne wline>) 

<moduie_spec>    ->    <spec_header> 

(<indent><newiine><param_biocK>)  ? 
<indent><newline><spec_block> 

<spec_header>    ->    'SPEC    <spec_id>    '15' 

<param_biock>   ->    f PARAMETERS  '    <indent><newline> 

<sp  ec_ hlock> 

'EEFINED_3Y'    <indent> 

<spec_id>   ->    <identifier> 

<spec_biock>    ->     (<extend_f or m>    <inlent>    <newlice>) ? 

( <s,,ec_ooiy>  l<paraa_cail>) 

<spec_boiy>    ->   <sort_r>ody>    <rewline> 

<op_body>    <newline> 
<axio4n_body>? 

<extend_f orm>    ->    'EXTEND'    <n«iwline> 

<indent>   <extend_iist> 

lv:iTH'<inder.t> 

<extend_list>    ->     ( (<spec_id> J<param_call>) ' ; • <nevline>}  + 
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<L  ara.T,_cuil>    ->    <spec_id>    '  (*    <st)ec_ic>    '}'    <:*ewline> 

<indent>    'WHERE'    <newline>    <^..J=..N 

<actual__paraa> 

<actual_param>   ->    <actual_sorts>    <newiine>   <actual_ops> 

<actua!_sorts>    ->    ' ACTUAL_SOBTS' 

(<ne  wiineXin  den  t><  sort  _id>'  IS  '    <sort_id>  '  ;  ')  + 

<actual_ops>    ->    'ACTUAL_OPS' 

(<newIii:e><indent><op_id>  '  IS  '    <op_id>'  ;')  + 

<sort_body>    ->    'SOLI'    <newline> 

<indem:>  (<sort_id>'  ;  ')  + 

<sort_id>   ->    <identifier> 

<oj_^ody>   ->    'OPERATIONS'  <n€wline> 

<indent>  <primitive_ops>   <newline> 

(<indent>  <derived_op.s>    <nawline>) ? 

(<indent>  <error_ops>    <newline>) ? 

(<indent>  <hidden_ops>    <newline>) ? 

<priiaitive_ops>    ->    'PRIMITIVE'    <newline> 

<inJent>    <operations> 

<der ivcd_ops>    ->    'DERIVED1    <newline>    <indent> 

<operations> 


-    v, 


<error_ops>    ->    ' ERROn'    <nnrr.liiie>    m 

<hiud«sn_op3>    ->    'HIDDEN1    <iie*iline>    <j.ndent> 

■Cope  rat  ions > 

<operations>    ->     (<op_£oria>    •  ;'    <newline>)  + 

<op_.:orui>    ->    <op_id>    ':'    <sort_list>?    '  -> '    <sort_id> 
<sort_list>    ->    (<sort_id>     ( «  ,' <sort_id>) .*) ? 
<axicm_i)ody>    ->    'AXIOM'    <indent>     (<newline>    <axioms>)+ 
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<axioms>    ->    <expression>     '='    <expression>    ';' 

<fcXi-ressiori>    ->     (<sort_id>  ]  <  cp_exp>) 

<op_exp>   ->    <op_id>     (' ('     <ex  j:ression> 

(' ,  '  <expression>)  *    •)') 


lexical    grammar 

<spectext>    ->     (<delimeter>+)  7    ]     (<delimeter_pair>+) ? 

<deiimeter>    ->    <comment>     |     '  -> '     |     ';'    |     '  ('     I     ')'     1 

','       1     •=•     |     ':• 

<non_delimete  r>    ->  <ident  if  i€r>    1     <stri.ng_constant> 

<identixier>    ->    <letter>     (<letter> ]<digit>| • _« ) * 

<string_constant>    ->    * '■     <synbol>*    ,lf 


<ietter>    ->    »A» 
»  K' 

•  U' 
■  e' 
'  o» 

•   XT  « 


r 


'B'l'C'I'D' 
1 1  •  J  « M  »  |  •  N ■ 
•  V  *  J  »  17 «  |  •  X ' 
'  £  '  j  •  g '  |  '  h » 
»p«  |'g«  |  'r' 


'  z1 


•E'  1  'F'  |  'G' 

«o«  i « p'  i « a« 

'Y»  |  «Z»  I  'a' 


•  i«  jt-ji 


ic  i 


s' | ' t' | ' a 


«  n » 


'   'A  t 


fxV 


b'| 


t  »l 


V  I 


I '  I '  J  •  i 


c1 

ID' 


'd«  i 
'n'j 
'x'  j 


<digit>    ->    '0 ' j  ' 1 ' | ' 2' j ' 3' | ' 4' 1 '5 ■ j '6' | ' 7' j ' 8 ' j  1 ?' 

<newiine>   ->     (<cominent>  j  <car  riage_returii>)  + 

<comment>    ->     ('  !  '  (<symbol>  j  <  let t er>)  +    <carriage_return>)  + 

<symboi>  ->    <letter> j <digit>  |  * j « J •»» | «# « | • $» J ■ ^ * | 
'  ' i  '&« j  • *' j  '  (' ]  ' )  ' | '-'  | '_' | »  +  ' j 

i  ii  j  i  tn  1 1  j  ij  i  j  i  t  ji  =  i  j  ,     »  |  '/'  j 

1  -'  I  '  .'1  '/' I '  {' I  ,0' i ■<• i  '>•  |  •  ;• I 
1  .  i 


<indent>   ->     ('     '+    J    <tab>) 
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